Agentes de IA para empresas: antes de implantar uno.

Es un sistema diseñado para avanzar una misión concreta utilizando un modelo de IA, conocimiento autorizado y, cuando hace falta, herramientas de la empresa. Puede interpretar una petición, consultar información, preparar una respuesta, proponer una acción o ejecutar pasos delimitados.

La diferencia importante no es que “converse”, sino que trabaja dentro de un circuito: recibe una entrada, aplica criterios, utiliza fuentes, produce un resultado y sabe cuándo debe detenerse o pedir revisión. Por eso un agente empresarial no debería definirse solo con un nombre y un prompt, sino con misión, propietario, fuentes, permisos, límites, pruebas y Human Gates.

Un chatbot general responde dentro de una conversación y, por defecto, no conoce los procesos, las versiones documentales ni las responsabilidades específicas de la empresa. Un agente se configura para una función delimitada y puede trabajar con fuentes y herramientas autorizadas.

Eso no significa que cualquier agente sea mejor que un chat. Para explorar ideas, redactar un primer borrador o hacer una consulta puntual, un asistente conversacional puede ser suficiente. El agente tiene sentido cuando existe una tarea repetida, un criterio estable, un recorrido reconocible y un resultado que puede evaluarse.

No exactamente. Una automatización clásica sigue reglas previsibles: si ocurre A, ejecuta B. Un agente puede interpretar lenguaje, contexto o documentos y decidir qué paso delimitado corresponde dentro de un conjunto de opciones.

Muchos buenos sistemas combinan ambas cosas. Las partes deterministas —mover un archivo, actualizar un campo o enviar una notificación aprobada— se resuelven con automatización. La IA entra donde hay que clasificar, resumir, comparar, extraer o preparar una recomendación. Esta separación reduce coste, variabilidad y riesgo.

Técnicamente puede ejecutar secuencias sin intervención constante, pero “puede” no significa “conviene”. El nivel de autonomía debe ajustarse al impacto de la acción, la sensibilidad de los datos, la reversibilidad y la calidad de las pruebas.

Consultar y preparar suele requerir menos control que publicar, enviar, modificar registros, comprometer presupuesto o tomar decisiones sobre personas. En estos puntos, Karmina sitúa Human Gates: momentos en los que una persona puede ver fuentes y contexto, revisar el resultado, corregirlo y autorizar el siguiente paso.

Una plantilla ayuda a repetir una petición. Un agente, cuando está bien diseñado, puede recuperar el contexto correcto, seleccionar herramientas, mantener estado dentro de un proceso, aplicar reglas diferentes según el caso y registrar qué ha hecho.

La pregunta práctica es si esa capacidad adicional resuelve una fricción real. Si una persona puede obtener un resultado fiable con una plantilla, una fuente clara y dos minutos de revisión, construir un agente puede ser innecesario. La arquitectura debe ganarse con valor, no con complejidad.

Tiene sentido cuando existe un trabajo que se repite, consume tiempo cualificado y necesita interpretar texto, documentos, datos o contexto antes de producir un resultado. También debe existir suficiente estabilidad: entradas reconocibles, fuentes disponibles, criterios que el equipo pueda explicar y una persona responsable del proceso.

Algunas señales favorables son preguntas internas recurrentes, informes que se reconstruyen cada mes, clasificaciones manuales, primeros borradores con una pauta común o información dispersa que siempre acaba buscando la misma persona. La decisión no debería nacer de “queremos tener un agente”, sino de “esta fricción tiene suficiente volumen y estructura para probar una forma mejor de resolverla”.

Un buen candidato tiene un principio y un final identificables, entradas que pueden describirse, un resultado útil para alguien y suficientes ejemplos para distinguir una respuesta buena de una deficiente. También conviene que las excepciones sean visibles y que los errores puedan detectarse antes de provocar un impacto grave.

La frecuencia importa, pero no es el único factor. Una tarea semanal puede justificar un agente si concentra mucho criterio o desbloquea a varias personas. En cambio, una tarea diaria puede no justificarlo si cambia constantemente, no tiene una fuente fiable o la única manera de evaluarla es “ya veremos cuando salga”.

No conviene cuando el proceso aún no se entiende, cada caso se resuelve de forma completamente diferente o las fuentes son contradictorias y nadie puede decidir cuál tiene autoridad. Tampoco cuando el error puede afectar a derechos, seguridad, reputación o dinero y no existe una revisión proporcional.

Otras señales de alerta son querer sustituir una responsabilidad que nadie quiere asumir, utilizar el agente para dar apariencia de objetividad a una decisión subjetiva o automatizar una tarea con tan poco volumen que mantener el sistema costará más que hacerla. A veces la mejor primera intervención es una plantilla, una política, una base documental o una automatización sencilla.

Normalmente es mejor empezar por un agente o un circuito muy delimitado que permita probar fuentes, permisos, calidad, tiempo ahorrado y comportamiento ante excepciones. Un piloto bien elegido produce aprendizajes que después pueden reutilizarse: taxonomías, conectores, métricas, políticas y formas de revisión.

El ecosistema tiene sentido cuando varios agentes comparten conocimiento y responsabilidades sin duplicarse. Por ejemplo, escuchar conversaciones, preparar un calendario, revisar el tono y publicar son funciones distintas. Conectarlas demasiado pronto puede crear dependencias difíciles de explicar. Primero hay que demostrar cada función; después decidir cuáles comparten base y cómo se pasan el trabajo.

El departamento ayuda a identificar propiedad, vocabulario y riesgos, pero el diseño debe seguir el proceso real. Muchos trabajos atraviesan áreas: una propuesta comercial puede necesitar ventas, operaciones, legal y marca; una respuesta de atención puede depender de producto, logística y comunicación.

Por eso conviene dibujar quién aporta cada fuente, quién valida cada criterio y quién utiliza el resultado. El agente puede tener un área propietaria y a la vez servir a un circuito transversal. Lo que debe evitarse es construir una solución encerrada en un departamento que reproduzca información o reglas diferentes de las del resto de la empresa.

Necesita la información estrictamente relacionada con su misión: procedimientos, criterios, definiciones, ejemplos, plantillas, políticas y datos operativos cuando sean necesarios. Darle “todos los documentos de la empresa” no crea automáticamente más contexto; a menudo introduce versiones antiguas, contradicciones e información que no debería consultar.

El mapa de fuentes debe explicar qué contiene cada repositorio, quién es responsable, con qué frecuencia se actualiza y en qué casos puede utilizarse. También son valiosos los contraejemplos: respuestas que parecen correctas pero vulneran el tono, un límite o una política. Este material convierte conocimiento implícito en criterio aplicable.

En muchos casos no. La primera opción suele ser conectar el modelo con fuentes recuperables y autorizadas para que consulte la información relevante en el momento de responder. Esto facilita actualizar contenido, mostrar citas, respetar permisos y retirar una fuente sin tener que volver a entrenar nada.

El ajuste o entrenamiento específico puede tener sentido para estabilizar un comportamiento, un formato o una clasificación cuando existen suficientes ejemplos de calidad. No es la solución adecuada para memorizar documentación cambiante. Antes de elegir arquitectura, hay que separar tres necesidades distintas: conocer información, seguir instrucciones y producir un estilo consistente.

Con gobernanza documental: una fuente canónica para cada tipo de información, responsable identificado, fechas de revisión, control de versiones y reglas de prioridad cuando dos fuentes discrepan. El agente debería poder indicar de dónde sale una afirmación importante y reconocer cuando la información no es suficientemente clara.

También hay que probar consultas que expongan conflictos de forma deliberada: precios antiguos, políticas sustituidas, nombres parecidos o documentos sin fecha. La solución no es pedir al modelo que “sea riguroso”, sino limitar el corpus, añadir metadatos útiles y definir qué debe hacer ante una contradicción: detenerse, citar las dos fuentes o escalar la pregunta.

Solo cuando la finalidad lo justifica, la herramienta y la configuración son adecuadas y el acceso respeta las mismas restricciones que ya tiene la organización. Hay que minimizar datos, evitar copias innecesarias, separar entornos y revisar las condiciones de tratamiento, retención, ubicación y uso para entrenamiento del proveedor.

La pregunta no es solo si el modelo “es seguro”, sino quién puede activar el agente, qué registros puede consultar, qué aparece en los logs, qué información sale en el resultado y quién la recibirá. Para datos especialmente sensibles o decisiones sobre personas, hay que involucrar a los responsables jurídicos, de privacidad y de seguridad antes del piloto.

Es la base gobernada de conocimiento y criterios que permite describir qué sabe la organización, qué fuente tiene autoridad, quién puede validarla, qué permisos se aplican y cómo se comprobará que el sistema responde bien. No es solo una carpeta de documentos ni una base vectorial.

Va antes porque el agente amplifica lo que recibe. Si el vocabulario, las políticas, los procesos o los ejemplos están incompletos, la automatización no resuelve el vacío: lo hace más rápido y menos visible. Construir la Foundation puede revelar que una parte del proyecto es tecnológica y otra es una decisión organizativa que la empresa todavía debe tomar.

Depende de la especificidad del proceso, las integraciones, los requisitos de datos y la capacidad de mantenimiento. Una solución existente es adecuada cuando resuelve una necesidad común y permite gobernar usuarios, datos y resultados. Una plataforma configurable da más flexibilidad sin asumir todo el desarrollo. El código a medida se reserva para flujos diferenciados, integraciones complejas o controles que el mercado no cubre.

La decisión no debería tomarse solo por el coste inicial. También cuentan la dependencia del proveedor, la portabilidad del conocimiento, los límites de uso, la trazabilidad, la velocidad de cambio y quién podrá mantener el sistema dentro de un año. En muchos proyectos, la mejor arquitectura es híbrida y utiliza herramientas que la empresa ya tiene.

Primero se definen las pruebas y después se comparan modelos. Los criterios pueden incluir calidad en los casos reales, coste por operación, velocidad, longitud de contexto, tratamiento de datos, disponibilidad regional, capacidad de utilizar herramientas, observabilidad y compatibilidad con la infraestructura existente.

No siempre hace falta el modelo más potente. Una clasificación estable puede funcionar con uno más pequeño; un análisis complejo puede necesitar uno avanzado; una acción sensible puede requerir una segunda comprobación o no ejecutarse automáticamente. Separar funciones permite utilizar el recurso adecuado para cada paso y evita atar todo el sistema a una sola marca.

Puede integrarse con gestores documentales, CRM, herramientas de proyectos, correo, analítica, bases de datos, formularios, help desks o canales de publicación, siempre que exista una interfaz segura y permisos compatibles. La integración no implica necesariamente dar capacidad de escritura: a menudo conviene empezar con consulta o preparación de borradores.

Cada conector amplía utilidad y superficie de riesgo. Hay que definir qué acciones son de lectura, cuáles son reversibles, cuáles necesitan aprobación y qué ocurre si una herramienta no responde. También debe registrarse suficiente información para reconstruir el circuito sin guardar más datos de los necesarios.

No existe un plazo universal. Un prototipo con fuentes preparadas y sin integraciones puede existir rápidamente; convertirlo en un sistema fiable suele requerir más tiempo para ordenar conocimiento, definir permisos, crear pruebas, resolver excepciones, formar a usuarios y preparar el mantenimiento.

El calendario depende menos del número de pantallas que de la disponibilidad de responsables y evidencias. Una secuencia realista incluye diagnóstico, diseño del piloto, preparación de la Foundation, configuración, evaluación con casos reales, uso en sombra, ajuste y decisión de despliegue. Acelerar saltándose estas fases solo traslada el tiempo a incidencias posteriores.

Como mínimo hace falta una persona propietaria del proceso, personas expertas que puedan explicar el criterio, un responsable técnico o de integraciones cuando corresponda y representación de seguridad, privacidad o legal según el riesgo. También conviene incluir a usuarios reales, porque detectan fricciones que no aparecen en un diagrama.

El proveedor puede facilitar diseño e implantación, pero no puede inventar la autoridad de las fuentes ni asumir la responsabilidad operativa de la empresa. El proyecto funciona mejor cuando los roles están escritos: quién decide, quién valida, quién puede detener el sistema, quién revisa métricas y quién actualiza el conocimiento.

Se reducen limitando la misión, recuperando información de fuentes fiables, exigiendo citas cuando son relevantes, mejorando instrucciones y ejemplos, y permitiendo que el sistema diga que no lo sabe. También ayuda separar la extracción de datos de la redacción y validar automáticamente formatos o campos que tienen una regla objetiva.

No existe el riesgo cero. Por eso hay que medir los tipos de error que importan en ese proceso y decidir qué ocurre cuando aparecen. Una respuesta sin fuente puede quedar como borrador; un dato crítico puede necesitar una comprobación; una contradicción puede activar un escalado. El control es una propiedad del circuito completo, no una frase dentro del prompt.

Con un conjunto de casos representativos que incluya ejemplos habituales, casos límite, información incompleta, instrucciones ambiguas, intentos de desviar el sistema y situaciones en las que debe detenerse. Cada prueba necesita un resultado esperado o una rúbrica que permita valorar exactitud, utilidad, fuentes, tono y cumplimiento de los límites.

Después de la prueba controlada conviene un periodo en sombra: el agente prepara resultados pero no actúa, y el equipo los compara con el proceso habitual. Esta fase revela errores, tiempo real de revisión y comportamientos inesperados. Solo se amplía la autonomía cuando las evidencias justifican el cambio.

Es un punto explícito del proceso donde una persona revisa información suficiente y decide si el sistema puede continuar. No es una aprobación simbólica: la interfaz debe mostrar el resultado, las fuentes, los cambios propuestos y los avisos necesarios para que la persona pueda corregir o rechazar.

Es especialmente importante antes de publicar, enviar comunicaciones sensibles, modificar datos maestros, eliminar información, compartir datos, comprometer dinero o tomar decisiones que afectan a personas. La intensidad del Gate puede variar: revisión de cada caso, revisión por muestreo, doble aprobación o escalado solo cuando aparece una excepción.

Además de los riesgos habituales de acceso y datos, un agente puede recibir instrucciones maliciosas dentro de un documento o una web, utilizar una herramienta fuera de contexto, revelar información, encadenar errores o aceptar como fiable una salida manipulada. Cuantas más herramientas y autonomía tiene, más importante es separar permisos y validar cada paso.

Las medidas incluyen privilegio mínimo, listas de acciones permitidas, aislamiento de entornos, validación de entradas y salidas, protección de secretos, registros, límites de gasto o frecuencia y pruebas adversarias. Las fuentes externas deben tratarse como datos no fiables, aunque el texto parezca una instrucción dirigida al agente.

Depende del rol de la organización, la finalidad y el contexto de uso. No todos los agentes son de alto riesgo, pero una empresa debe inventariar los sistemas, entender para qué se utilizan, aplicar medidas de alfabetización, revisar prácticas prohibidas e identificar si existen obligaciones de transparencia o requisitos sectoriales.

El agente debe clasificarse por lo que hace, no por el nombre comercial de la herramienta. Un asistente interno de consulta no plantea el mismo nivel de riesgo que un sistema utilizado en empleo, servicios esenciales o decisiones sobre personas. La clasificación y la documentación deben revisarse con asesoramiento jurídico especializado cuando el caso pueda entrar en ámbitos regulados.

El coste depende del diagnóstico, la preparación de fuentes, las integraciones, el nivel de autonomía, las pruebas, la seguridad y el mantenimiento. Una demostración puede ser barata porque ignora gran parte de este trabajo; un sistema empresarial incluye decisiones y controles que no se ven en la interfaz.

Para comparar propuestas conviene separar cinco bloques: diseño y criterio, Foundation, configuración o desarrollo, infraestructura y uso, y operación continuada. También hay que contar el tiempo interno de personas expertas y revisoras. El presupuesto es más honesto cuando explica qué queda fuera, qué hipótesis se probará y qué haría aumentar el alcance.

Primero se mide la situación actual: volumen, tiempo por caso, tiempo de espera, errores, retrabajo, dependencias y valor del resultado. Después se compara con el piloto, incluyendo el tiempo de revisión humana, el coste de uso y el mantenimiento. Ahorrar minutos no es retorno si la calidad baja o el equipo debe corregir más.

El retorno puede aparecer como capacidad, rapidez, consistencia, reducción de riesgo o mejor servicio, no solo como reducción de costes. Hay que elegir pocas métricas vinculadas a una decisión: continuar, ajustar, ampliar o detener. Las estimaciones iniciales son hipótesis; el piloto existe para sustituirlas por evidencia.

Dependen de la misión. Pueden incluir exactitud, porcentaje de respuestas con fuente, cumplimiento del formato, tiempo hasta el resultado, tasa de aceptación sin cambios, tipos de correcciones, escalados correctos, incidencias y satisfacción del usuario. Las métricas de actividad —número de consultas o documentos generados— no demuestran por sí solas valor.

Conviene combinar calidad, operación y riesgo. Por ejemplo: una respuesta puede ser rápida pero no resolutiva; un informe puede cumplir la estructura pero interpretar mal una métrica. Las muestras revisadas por expertos y la taxonomía de errores ayudan a ver tendencias que una media ocultaría.

Hay que mantener fuentes, permisos, integraciones, instrucciones, modelos, pruebas y métricas. También deben revisarse cambios de proceso, nuevas excepciones, incidencias, costes de uso y actualizaciones de los proveedores. Un agente conectado a conocimiento vivo no es un proyecto que se entrega y queda congelado.

El mantenimiento debe tener propietario y cadencia. Algunas revisiones son operativas y frecuentes; otras son trimestrales o se activan cuando cambia una política, una fuente o una herramienta. Las modificaciones importantes deben probarse contra el conjunto de evaluación antes de desplegarlas, igual que se haría con cualquier sistema que afecta al trabajo.

Elegir una fricción concreta y describirla sin hablar todavía de herramientas: quién inicia el trabajo, qué entradas utiliza, qué decisiones aplica, qué resultado produce, qué excepciones aparecen y quién responde de la calidad. Después se mide el punto de partida y se revisa si existen las fuentes y los permisos necesarios.

Con esa información puede decidirse si hace falta una plantilla, una automatización, un asistente o un agente. Si el agente es la respuesta, se define un piloto con alcance, Human Gates, pruebas y criterio de salida. Empezar pequeño no significa pensar pequeño: significa construir evidencia antes de aumentar autonomía y dependencias.