Hay una conversación que suele aparecer tarde en los proyectos de implementación de AI: la de los límites.
¿Qué pasa si el agente comete un error y ejecuta una acción que no debería? ¿Quién es responsable si el sistema cancela un turno que el paciente no quería cancelar? ¿Qué pasa si el agente le da información de cobertura a alguien que no es el afiliado?
Estas preguntas son válidas. Y la forma en que el proveedor las responde es uno de los indicadores más claros de si el sistema está listo para producción en salud y seguros o no.
El miedo legítimo detrás de la pregunta
El miedo no es irracional. Los responsables de tecnología y operaciones en clínicas y aseguradoras han visto lo que pasa cuando un sistema falla en silencio: un proceso automatizado que dejó de funcionar, un dato que se actualizó mal, un caso que cayó en un limbo entre sistemas.
La AI agrega una dimensión nueva a ese riesgo: el sistema no solo puede tener un bug técnico, también puede malinterpretar una instrucción del cliente y ejecutar algo que no era la intención.
"Quiero cancelar" puede significar cancelar el turno de mañana, cancelar todos los turnos futuros, o cancelar la cuenta completa. Un sistema que no distingue entre estas tres interpretaciones, o que no confirma antes de ejecutar, es un sistema que en algún momento va a cometer un error con consecuencias reales.
Los límites tienen que estar en código, no en instrucciones
La forma habitual de intentar resolver esto es a través de instrucciones al sistema: "no canceles servicios sin confirmación explícita del cliente", "no des información de cobertura sin verificar la identidad del afiliado".
Las instrucciones son necesarias. No son suficientes.
Un sistema de AI que sigue instrucciones lo hace estadísticamente: la enorme mayoría de las veces, pero no siempre. En un volumen de miles de conversaciones por mes, "la enorme mayoría de las veces" implica una cantidad de errores que en salud y seguros puede tener consecuencias serias.
Los límites que importan en producción no son los que el sistema intenta seguir. Son los que el sistema no puede violar, porque están implementados como controles técnicos que se ejecutan antes de cualquier acción.
La diferencia práctica: con instrucciones, el agente podría cancelar un turno sin confirmación si la conversación es suficientemente ambigua y el modelo interpreta mal la intención. Con controles técnicos, el agente no puede ejecutar esa acción sin que el código haya verificado que la confirmación existe.
Los tres tipos de acciones
No todas las acciones de un agente tienen el mismo nivel de riesgo. Un sistema bien diseñado trata cada una de forma diferente.
Acciones de solo lectura: consultar el estado de un turno, ver la cobertura de un plan, informar el estado de un reintegro. El riesgo es bajo — el peor caso es dar información incorrecta, que puede corregirse. Estas acciones pueden ejecutarse con fluidez, sin friction adicional.
Acciones reversibles con impacto moderate: reprogramar un turno, actualizar un dato de contacto, iniciar una solicitud de autorización. El riesgo es medio — el error es corregible pero genera trabajo. Estas acciones requieren que el sistema tenga alta confianza en la intención del cliente antes de ejecutarlas, y en muchos casos una confirmación explícita.
Acciones irreversibles o de alto impacto: cancelar una suscripción, dar información de salud sensible, ejecutar un pago, modificar datos médicos. El riesgo es alto — el error tiene consecuencias directas que pueden ser difíciles de revertir. Estas acciones requieren confirmación explícita del cliente, verificación de identidad apropiada, y en algunos casos, aprobación de un operador humano antes de ejecutarse.
Un agente que no tiene esta distinción implementada —que trata una consulta de horarios igual que una cancelación de póliza— no está listo para un entorno de producción en salud y seguros.
El handoff humano: cuándo el agente debe pasar la pelota
Saber cuándo no proceder es tan importante como saber qué hacer.
Hay situaciones donde la respuesta correcta del agente no es ejecutar ni negarse: es escalar a un humano. Los casos más comunes en salud y seguros:
El cliente expresa una situación de urgencia médica o emocional que requiere atención humana. El agente puede hacer muchas cosas, pero no puede reemplazar el juicio clínico ni la empatía de un profesional en momentos críticos.
La consulta cae fuera del dominio configurado del agente. Si el agente está configurado para gestión de turnos y el cliente pregunta algo que requiere interpretación médica, la respuesta correcta es derivar — no inventar.
La intención del cliente es genuinamente ambigua después de intentar clarificarla. Antes que ejecutar algo incorrecto con alta confianza equivocada, el agente bien diseñado escala.
El escalado no es una señal de falla del sistema. Es una señal de madurez. Un agente que escala cuando corresponde genera más confianza que uno que siempre intenta resolver — y a veces se equivoca.
La pregunta que hay que hacerle al proveedor
Cuando evaluás un proveedor de AI para salud o seguros, pedí que te expliquen concretamente: ¿cómo funciona el sistema de límites?
Las respuestas a buscar: - "El agente tiene configurado qué acciones puede ejecutar de forma autónoma y cuáles requieren confirmación explícita del cliente." → Indica que hay un sistema de controles por tipo de acción. - "Hay una capa técnica que verifica las condiciones antes de ejecutar — no depende solo de la instrucción al modelo." → Indica que los límites no son solo instrucciones. - "Podés ver en el audit trail qué decidió el agente en cada conversación y por qué." → Indica que el sistema es auditable.
Si la respuesta a estas preguntas es vaga — "el modelo es muy bueno en seguir instrucciones", "tenemos un prompt muy detallado" —, no es suficiente para un entorno donde los errores tienen consecuencias.
Lo que cambia cuando el sistema dice que no bien
Un agente que tiene límites bien implementados no es un agente más restrictivo. Es un agente más confiable.
La confianza operativa que genera — en el equipo de compliance, en los directores médicos, en el equipo legal — es la que permite que la empresa adopte el sistema con más amplitud. El miedo inicial a "qué pasa si se equivoca" se convierte en "sabemos exactamente qué puede hacer y qué no puede hacer".
Esa confianza es la condición necesaria para escalar. Las empresas que implementan AI con controles claros terminan usando más capacidades del sistema. Las que implementan sin controles —o con controles solo en instrucciones— terminan restringiendo el uso del agente por miedo a los errores.
El costo de implementar bien los límites es de diseño y configuración upfront. El costo de no implementarlos es operacional y reputacional, y llega después.
Fidelia AI es una plataforma de agentes conversacionales para empresas de salud, seguros y servicios financieros. Cada agente que construimos tiene un sistema de controles explícito: qué acciones puede ejecutar de forma autónoma, cuáles requieren confirmación, y cuáles requieren un humano. Es parte del diseño, no un agregado posterior.
