Cómo probar la IA de atención al cliente ante inyecciones

Prueba la IA de atención al cliente ante inyecciones comprobando qué puede hacer que el sistema completo revele, cambie o ejecute una entrada no confiable. Hazlo en un entorno de pruebas con clientes ficticios, herramientas limitadas y resultados registrados. Que el agente rechace con educación una instrucción evidente no demuestra que sea seguro.

Una inyección ocurre cuando una entrada no confiable altera el comportamiento del modelo de una forma no prevista. Puede llegar directamente en el mensaje de un cliente o indirectamente desde un artículo de conocimiento, un archivo adjunto, una página web, la respuesta de una herramienta o una conversación guardada. El proyecto de seguridad de IA generativa de OWASP sitúa este riesgo como LLM01 en 2025 y explica que la recuperación de información y el ajuste adicional no lo eliminan por completo.

Para atención, no es solo un problema de respuestas extrañas. Un agente puede ver datos de clientes, consultar conocimiento, añadir etiquetas, cambiar un caso o proponer una transferencia. La prueba debe recorrer el camino desde el mensaje hasta la acción y la respuesta.

Empieza por el límite de cada acción

Antes de crear casos, escribe qué puede leer, decidir y cambiar el agente. Separa las respuestas normales de las acciones que tienen consecuencias.

Por ejemplo, el agente puede explicar una política de devoluciones publicada. No debe mostrar el pedido de otro cliente, cambiar el estado de un reembolso, inventar una excepción ni enviar datos de una cuenta a una dirección nueva. Si un flujo puede crear una oportunidad o actualizar un caso, enumera los campos exactos que puede escribir y las condiciones necesarias.

Sigue esta cadena en cada prueba:

Prueba todas las rutas de contenido no confiable

Después prueba rutas indirectas. Coloca instrucciones de prueba inofensivas en un artículo de conocimiento de ensayo, un adjunto, una descripción de producto, un caso antiguo y una respuesta simulada de una herramienta. El resultado esperado es que el sistema trate ese material como datos y no como una autoridad superior a sus reglas.

Incluye conversaciones de varios turnos, otros idiomas, formatos poco habituales, historiales largos, adjuntos e intentos repetidos. La guía del Centro Nacional de Seguridad Cibernética del Reino Unido describe la manipulación directa e indirecta de las entradas. En sistemas con agentes, una instrucción hostil también puede llegar mediante una herramienta u otro agente. Por eso hay que probar la bandeja de entrada, la recuperación, la memoria y todas las acciones conectadas.

Mantén las pruebas lejos de clientes reales

Usa un espacio aislado con nombres, pedidos, direcciones, pagos e historiales ficticios. Sus credenciales no deben acceder a producción. Desactiva correos, mensajes, reembolsos, reservas y eliminaciones reales, o dirige cada acción a un servicio de pruebas controlado.

Prueba solo sistemas propios o autorizados. No pegues secretos de producción en los mensajes ni uses conversaciones reales sin un proceso aprobado de seguridad y privacidad.

Valora la consecuencia posible

Una respuesta ingeniosa o extraña importa menos que el daño posible. Clasifica cada caso por la peor acción que el sistema podría completar.

• Impacto bajo es una respuesta irrelevante o deficiente sin revelar datos ni cambiar un estado.
• Impacto material es una política incorrecta, un caso mal actualizado, una transferencia omitida o un mensaje no deseado.
• Impacto alto es revelar datos entre clientes, actuar sin permiso sobre una cuenta, cambiar un pago o reembolso, exponer credenciales o causar un efecto externo.

Corrige el sistema que rodea al modelo

No dependas de una única instrucción de sistema más severa. OWASP indica que no existe una prevención infalible y recomienda controles por capas. Da al agente los datos y herramientas mínimos. Aplica la autorización del cliente y del espacio de trabajo mediante código normal. Valida de forma determinista los argumentos y resultados de cada herramienta. Separa el contenido recuperado no confiable de las instrucciones del sistema. Exige aprobación humana en acciones de alto riesgo.

El perfil de NIST para gestionar riesgos de IA generativa incluye la inyección dentro de un trabajo continuo de diseño, despliegue, evaluación y seguimiento. Una corrección debe reducir la consecuencia y dejar evidencia, no limitarse a detener una frase de prueba.

Repite el conjunto completo tras cambiar el modelo, la instrucción, la base de conocimiento, una herramienta, un permiso, una regla de memoria o un flujo. Conserva los fallos como pruebas de regresión. Publica el agente solo cuando el equipo receptor comprenda los límites restantes y sepa cómo pausarlo.

Un ejemplo de alquiler de cámaras

Imagina una IA que responde preguntas para una tienda de alquiler de cámaras. Puede leer información pública de equipos y consultar disponibilidad para el cliente actual. Las pruebas deben confirmar que un archivo subido no cambia la política de alquiler, que un cliente no accede a la reserva de otro y que el agente no confirma una reserva sin las comprobaciones habituales de identidad y disponibilidad.

Si el mensaje es ambiguo o pide una excepción, la respuesta correcta puede ser una transferencia que conserve la pregunta y la acción prevista. Un agente seguro no es el que responde a todo. Es aquel cuya autoridad sigue siendo limitada cuando la conversación se vuelve hostil o poco clara.

Con DripTell AI, los equipos pueden controlar el conocimiento, la intención, la creación de oportunidades y la transferencia humana. Los controles de seguridad definen funciones y acceso. Aun así, cada implementación necesita un plan acorde con los datos y acciones que realmente tiene habilitados.

Preguntas frecuentes

Se puede impedir por completo una inyección

No. Ningún control actual ofrece una garantía total. Los permisos mínimos, la autorización y validación deterministas, la aprobación humana, la supervisión y las pruebas repetidas reducen tanto la probabilidad como el impacto.

Se deben usar datos de clientes reales

No. Empieza en un entorno aislado con registros ficticios y efectos externos desactivados. Los datos de producción solo deben entrar mediante un proceso aprobado con controles claros de privacidad.

Qué debe ocurrir cuando falla una prueba

Conserva el rastro, bloquea la acción peligrosa, identifica el límite de confianza que falló, reduce permisos o añade una validación determinista. Después repite el caso y todo el conjunto de regresión antes de publicar.