El agente que promete entrar mañana en cualquier empresa puede ser precisamente el agente que no entiende ninguna empresa.

TL;DR

Los agentes genéricos no son necesariamente inútiles. Pueden servir como demostración, prototipo o base reutilizable. El engaño empieza cuando esa base se vende como solución terminada sin descubrir el proceso, las fuentes, las excepciones, los permisos y las responsabilidades de la empresa. La primera experiencia suele fallar precisamente en los detalles que la demostración esconde. Después, la organización concluye que “la IA no funciona”, genera rechazo y puede quedarse atrás por culpa de una mala implementación, no por el límite real de la tecnología. Huye de quien llega con la solución antes de comprender el problema.

Imagina la propuesta.

Un agente de ventas listo.

Un agente financiero listo.

Un agente de atención al cliente listo.

Instalación rápida. Algunas integraciones. Una demostración en la que todo sucede en el momento adecuado y ningún cliente decide hacer la pregunta que no estaba en el guion.

Parece irresistible.

También puede ser la peor primera experiencia que tu empresa tenga con la inteligencia artificial.

No porque los agentes no funcionen.

Porque “agente genérico para empresas” puede ser una contradicción escondida detrás de una interfaz bonita.

Empresa no es un sustantivo suficiente para configurar un sistema.

La demostración vende la parte en la que todo se parece

Es fácil demostrar el camino habitual.

Llega un mensaje. El agente identifica la intención. Consulta una información. Responde. Quizá actualice un registro. Todos sonríen frente a la pantalla.

El problema real empieza después:

• ¿cuál es la fuente oficial cuando dos sistemas discrepan?
• ¿qué significa “cliente activo” en esa empresa?
• ¿quién puede conceder un descuento y hasta qué límite?
• ¿qué información puede mostrar el servicio de atención a cada perfil?
• ¿qué excepción necesita la aprobación de finanzas?
• ¿qué sucede cuando un documento llega incompleto?
• ¿qué acción puede deshacerse?
• ¿quién recibe el caso cuando el sistema no sabe?

La demostración muestra capacidad.

La operación exige contexto.

Es en ese intervalo donde muchas soluciones listas se convierten en un engaño, incluso cuando el modelo es bueno, la interfaz funciona y el proveedor no inició el proyecto con la intención de engañar a nadie.

El problema puede nacer de una promesa mayor que la arquitectura.

Un cargo genérico no contiene un proceso

“Agente de ventas” no describe un trabajo.

Las ventas pueden implicar prospección, calificación, historial de la relación, política comercial, cálculos, inventario, plazos, contratos, privacidad, transferencia al servicio de atención y decenas de excepciones que cambian de una empresa a otra.

“Agente financiero” es aún más peligroso como abreviación. ¿Qué parte de finanzas? ¿Conciliación? ¿Cobros? ¿Lectura de facturas? ¿Preparación de pagos? ¿Proyecciones? ¿Aprobaciones? Cada verbo exige datos, autoridad y controles diferentes.

“Agente de recursos humanos” puede significar localizar una política interna o participar en una decisión que afecta derechos y carreras. Usar el mismo nombre para ambos casos esconde una enorme diferencia de riesgo.

Un agente de IA es un sistema capaz de elegir los próximos pasos y usar herramientas dentro de un objetivo. El nombre del cargo no informa qué herramientas recibe, en qué fuentes debe confiar, qué decisiones puede tomar ni dónde debe detenerse.

Sin eso, no existe un cargo digital.

Existe una improvisación con credencial.

El agente genérico falla precisamente donde la empresa es específica

No falla necesariamente al resumir textos, hacer una clasificación simple o dar una respuesta habitual.

Falla cuando encuentra aquello que convierte un negocio real en algo diferente de la diapositiva comercial:

• una regla que nunca fue documentada;
• dos sectores que usan el mismo término con sentidos diferentes;
• un registro desactualizado que todos aprendieron a sortear;
• una excepción rara, pero costosa;
• una política que depende del perfil de quien hace la solicitud;
• una integración que funciona nueve veces y falla en silencio la décima;
• una decisión cuya responsabilidad nadie quiso asumir en el diseño del proyecto.

El agente no conoce estas cosas por intuición.

Es necesario descubrirlas, transformarlas en contexto y conectarlas con la operación.

A veces, ni siquiera la propia empresa consigue explicarlas a la primera. Por eso el levantamiento de requisitos no es una reunión burocrática antes de la instalación. Es el trabajo de hacer que el proceso sea lo bastante legible para que cualquier sistema —humano, convencional o asistido por IA— consiga operarlo.

Una mala primera impresión cobra intereses

Después de una mala implementación, la conclusión rara vez se limita al proveedor.

La gente dice:

• “la IA inventa demasiado”;
• “nadie confía en esto”;
• “lo intentamos y no funcionó”;
• “nuestra empresa es diferente”;
• “mejor seguir haciéndolo manualmente”.

Y quizá esté describiendo correctamente el sistema que recibió.

El problema es trasladar esa experiencia a cualquier uso futuro.

Existe una línea de investigación llamada aversión a los algoritmos, que investiga la tendencia a rechazar un sistema automatizado después de observar sus errores. En experimentos publicados por Dietvorst, Simmons y Massey, los participantes pasaron a evitar las previsiones algorítmicas después de verlas fallar, incluso cuando superaban en promedio a las previsiones humanas.

El estudio de 2015 abordó tareas experimentales de previsión, no la implementación de agentes de IA en empresas. No demuestra que una mala experiencia con un chatbot condene toda adopción futura. Sirve aquí como una lente limitada para algo que vale la pena considerar: las personas no evalúan solo la tasa de acierto; actualizan su confianza cuando ven cómo falla el sistema.

Una implementación irresponsable no solo desperdicia presupuesto.

Puede enseñar a la organización a rechazar una capacidad que todavía ni siquiera llegó a conocer bien.

La empresa también aprende un comportamiento equivocado

Cuando el agente listo se presenta como algo mágico, el equipo aprende dos opciones igualmente malas.

O debe confiar porque “la IA sabe”.

O debe rechazarlo todo porque la primera experiencia falló.

Ninguna de las dos enseña un uso responsable.

Una adopción madura debería enseñar a las personas a:

• reconocer para qué fue diseñado el sistema;
• verificar la fuente de una respuesta importante;
• distinguir entre sugerencia, validación y decisión;
• percibir cuándo la situación salió del contexto previsto;
• corregir el sistema sin esconder el error;
• derivar las excepciones a la persona responsable adecuada;
• medir si el proceso realmente mejoró.

La herramienta no entra solo en una arquitectura técnica.

Entra en una cultura de trabajo.

Si la primera lección es “haz clic y cruza los dedos”, puede que la tecnología parezca moderna. El aprendizaje organizacional no lo es.

Una base reutilizable es diferente de una respuesta lista

Yo mismo trabajo con una base reutilizable.

Sería un desperdicio reconstruir desde cero el control de versiones, la memoria, la gestión de permisos, el registro de acciones, los patrones de validación y los componentes de automatización cada vez que empieza un nuevo sistema.

También existen automatizaciones que pueden replicarse prácticamente tal cual cuando el proceso y las herramientas son equivalentes y solo exigen ajustes de configuración e integración.

El problema no es reutilizar la ingeniería.

El problema es reutilizar las conclusiones.

Una base responsable acelera lo que es estructural y mantiene explícito lo que necesita descubrirse:

Se puede reutilizar	Debe nacer del contexto
Estructura de memoria y trazabilidad	Qué información merece recordarse y durante cuánto tiempo
Patrones de herramientas y permisos	A qué sistemas puede acceder el agente y con qué autoridad
Mecanismos de validación	Qué significa una entrega correcta en ese proceso
Registros, monitoreo y alertas	Qué fallo importa, quién debe saberlo y cuándo actuar
Flujos de aprobación	Quién responde por cada decisión y qué límite exige un escalamiento
Componentes de integración	Qué datos son canónicos y cómo resolver divergencias reales

Un producto listo puede significar componentes maduros.

No debería significar un contexto imaginado.

Lo que suele faltar dentro de la caja

Un agente útil para producción necesita más que un modelo y un conjunto de instrucciones.

Necesita un harness: el sistema alrededor del modelo que proporciona contexto, memoria, herramientas, permisos, fuentes, validaciones, límites y ciclos de feedback.

En la práctica, eso incluye por lo menos:

1. Fuente de verdad

El agente necesita saber qué documento, base de datos o sistema contiene la información oficial. Cuando las fuentes discrepan, la regla de precedencia no puede inventarse durante la respuesta.

2. Vocabulario del negocio

Términos aparentemente simples —cliente, propuesta, pendiente, aprobado, concluido— necesitan tener el significado que se usa en esa operación.

3. Herramientas y permisos

Consultar es diferente de modificar. Preparar es diferente de enviar. Recomendar es diferente de aprobar. Cada acción necesita el menor acceso necesario y, cuando exista una consecuencia material, un punto de aprobación.

4. Casos de evaluación

Antes de entrar en producción, el sistema necesita enfrentarse a un conjunto representativo de situaciones reales: camino habitual, datos ausentes, información contradictoria, excepción, intento indebido y fallo de una herramienta. Evaluar no es preguntarle al proveedor si la demostración funcionó. Es comparar el resultado con criterios de aceptación definidos de antemano.

5. Observabilidad

La observabilidad es la capacidad de comprender el estado interno de un sistema a partir de evidencias como registros de eventos, métricas y rastros de ejecución. Sin ella, el agente puede fallar en silencio o producir una respuesta sin que nadie consiga reconstruir el camino.

6. Una forma segura de fallar

El sistema necesita poder abstenerse, pedir información, transferir el caso, interrumpir una acción y revertir lo que sea reversible. “No sé” puede ser una función de seguridad.

7. Responsable de la decisión

Si nadie puede responder quién autoriza, quién monitorea y quién corrige, el agente no recibió autonomía.

Recibió abandono.

La pregunta no es “¿cuánto hace en la demostración?”

Es fácil impresionar midiendo la cantidad de acciones.

Yo prefiero preguntar:

• ¿En qué situaciones no debe actuar?
• ¿Qué contexto se usó para configurar la demostración?
• ¿Qué casos reales se probaron?
• ¿Cómo muestra el sistema la fuente de una afirmación?
• ¿Quién define y modifica las políticas?
• ¿Qué permisos vienen activados por defecto?
• ¿Qué sucede cuando una integración no está disponible?
• ¿Existe un entorno de prueba separado de la operación real?
• ¿Cómo se detecta y revierte una acción incorrecta?
• ¿Bajo qué control quedan los datos y los registros?
• ¿La empresa puede cambiar de modelo, herramienta o proveedor?
• ¿Quién mantiene el sistema cuando cambia el proceso?

A un buen proveedor deberían gustarle estas preguntas.

Ayudan a vender menos fantasía y entregar más sistema.

Huye de quienes entregan soluciones listas

No huyas de quien trae componentes listos, experiencia acumulada o una arquitectura de referencia.

Huye de quien:

• presenta la solución antes de escuchar el proceso;
• llama implementación a una demostración;
• trata el acceso amplio como una facilidad de integración;
• promete autonomía sin explicar la autoridad;
• mide el éxito por la calidad de la conversación, no por el resultado del trabajo;
• no consigue mostrar cómo se evalúa el agente;
• vende la personalización como un cambio de nombre, logotipo y mensaje inicial;
• no habla de excepciones, seguridad, registros, costo, mantenimiento o reversión;
• culpa al usuario cuando el sistema encuentra una situación que nunca fue mapeada;
• crea dependencia sin ofrecer control sobre el contexto, los datos y la operación.

Una solución realmente madura no teme revelar lo que aún necesita descubrirse.

El contexto viene antes que el agente

El NIST AI Risk Management Framework incluye, en la función de mapear, la necesidad de comprender el propósito, el contexto de uso, los usuarios, los impactos, la supervisión humana y el alcance previsto del sistema. Es un marco voluntario y amplio; no certifica proveedores ni determina la arquitectura de un agente. Aun así, respalda un principio importante: el riesgo y la capacidad no pueden evaluarse fuera del contexto en el que se usará la IA.

Anthropic también recomienda empezar por la solución más simple y adaptar las capacidades al caso de uso. Es una referencia de ingeniería de la propia empresa, no una regla universal. Su valor está en el contraste con la venta del agente universal: una mayor complejidad solo merece existir cuando mejora un resultado que puede evaluarse.

El agente no debería llegar primero y buscar una función después.

Primero viene el trabajo.

Después, la arquitectura.

Así es como prefiero entregar

En la i-9.ai, puedo partir de componentes, patrones y automatizaciones ya maduros.

Pero la entrega empieza por comprender la operación: conversar con quienes la ejecutan, localizar el cuello de botella, levantar requisitos y mapear datos, decisiones, excepciones y responsabilidades. Solo entonces tiene sentido elegir entre proceso, integración, automatización determinista, IA asistiva, agente o decisión operacional delimitada.

Es el mismo principio que presenté en “Tu empresa no necesita descubrir dónde poner IA”: la tecnología entra después de que el trabajo atascado se vuelve visible.

Si recibiste una propuesta de “agente listo” y quieres entender qué hay dentro de ella, ponte en contacto. La conversación puede empezar por el proceso, los riesgos y lo que habría que demostrar antes de poner cualquier sistema en producción.

No dejes que una mala implementación defina el futuro

Tal vez tu primera experiencia con la IA haya sido realmente mala.

Tal vez el agente haya inventado, estorbado, exigido más comprobaciones que el proceso manual y desaparecido al encontrar la primera excepción.

Eso es evidencia sobre aquel diseño.

No es una prueba sobre todo lo que puede construirse.

Al mismo tiempo, no aceptes que la promesa de “ahora sí funcionará” sea suficiente para intentarlo de nuevo. La segunda experiencia necesita empezar con un método mejor, criterios más claros y una autoridad mucho más delimitada.

Los agentes genéricos pueden hacer que la empresa rechace la IA antes de conocerla.

El antídoto no es creer más.

Es exigir que la solución deje de ser genérica antes de recibir acceso a lo que es específico, valioso y real.

Sigue leyendo

• Tu empresa no necesita descubrir dónde poner IA: cómo empezar por el cuello de botella y elegir la menor intervención suficiente.
• La IA no es una sola cosa: modelo, agente, automatización y harness: las capas que una demostración suele esconder.
• La mejor respuesta no es la que más me agrada: por qué las fuentes, los puntos ciegos, los permisos y las validaciones forman parte de la capacidad.

Para profundizar

• Agente inteligente: contexto enciclopédico sobre sistemas que perciben un entorno y actúan para alcanzar objetivos.
• Ingeniería de requisitos: disciplina utilizada para descubrir, analizar y registrar las necesidades, restricciones y criterios de un sistema.
• Principio de mínimo privilegio: práctica de conceder únicamente los accesos necesarios para una función.
• Observabilidad: introducción a los registros, métricas y rastros utilizados para comprender sistemas en operación.
• Aversión a los algoritmos: panorama del concepto y de las investigaciones sobre el rechazo a sistemas algorítmicos después de observar errores.

Referencias y límites de uso

• Dietvorst, Simmons y Massey, “Algorithm Aversion: People Erroneously Avoid Algorithms after Seeing Them Err” (2015): artículo de los autores con experimentos sobre previsiones algorítmicas y reacciones a errores observados. No estudió agentes generativos, implementaciones empresariales ni demuestra que toda primera mala experiencia produzca un rechazo duradero.
• NIST, “Artificial Intelligence Risk Management Framework 1.0” (2023): marco voluntario para gobernar, mapear, medir y gestionar riesgos. Respalda la necesidad de documentar el contexto y el alcance; no evalúa ofertas comerciales específicas.
• Anthropic, “Building Effective Agents” (2024): orientación de la propia empresa para adaptar capacidades, mantener la simplicidad y añadir complejidad cuando exista una ganancia demostrable. No es una comparación independiente de proveedores.

Los ejemplos de fallos y las señales de alerta son una síntesis autoral de riesgos de arquitectura. No acusan a ningún proveedor específico, no demuestran fraude ni sustituyen una evaluación técnica, jurídica o de seguridad de una solución concreta.

La imagen de portada es una ilustración editorial sintética creada para contrastar un módulo genérico con una integración adaptada y gobernada.