IA y documentos adjuntos: cómo evitar órdenes no autorizadas

Un asistente puede resumir correctamente un PDF y, aun así, interpretar una frase del archivo como una orden. Si tu empresa usa IA para leer adjuntos, ofertas o fichas de clientes, conviene decidir qué ocurrirá cuando el contenido intente cambiar la tarea.

La inyección de instrucciones, o prompt injection, puede llegar desde archivos y páginas externas. OWASP la describe como una vía para alterar el comportamiento del modelo y advierte de que añadir documentos mediante RAG no elimina el riesgo. Consulta su explicación del problema.

Un adjunto informa, pero no autoriza operaciones

Ejemplo hipotético: una distribuidora recibe un PDF con un pedido. Su asistente debe extraer referencias, cantidades y fecha solicitada. En una nota del documento aparece una petición para sustituir la dirección de entrega y dar el cambio por aprobado.

Hay dos asuntos distintos: recoger que el cliente solicita otra dirección y autorizar la modificación del pedido. El resultado útil sería un borrador con el cambio señalado para revisión. El documento no demuestra que quien lo envió pueda modificar ese cliente ni que la nueva dirección esté validada.

La frase sospechosa puede ser visible. No hace falta buscar únicamente texto diminuto o escondido. Tampoco toda instrucción comercial es un ataque: «entregar por la tarde» puede ser un dato legítimo del pedido. La decisión depende de la tarea autorizada y del efecto que produciría.

Dibuja el recorrido del archivo hasta el CRM

Antes de añadir otro filtro, prepara una ficha del proceso: quién aporta el archivo, qué campos se extraen, dónde se guardan y qué paso produce un cambio real. Para el pedido del ejemplo proponemos esta separación:

1. Recepción y preparación

Conserva una referencia al adjunto y al pedido relacionado. El resultado de la extracción puede incluir referencias, cantidades y observaciones; una petición de cambiar la dirección queda marcada como incidencia. No permitas que el texto del PDF elija libremente el cliente que se va a modificar.

2. Revisión y ejecución

La pantalla de revisión debería mostrar la dirección actual, la propuesta, el pedido afectado y el fragmento que solicita el cambio. Si el revisor corrige el borrador, la aprobación debe corresponder a esa versión. Un mensaje genérico como «todo correcto» deja demasiadas preguntas abiertas.

La guía de prevención de OWASP recomienda validar permisos y parámetros fuera del modelo. También aclara que separar el texto mediante etiquetas no constituye por sí solo una barrera de seguridad.

En una integración con n8n, pide al implementador que identifique el paso exacto que escribe en el CRM y muestre qué comprobaciones se ejecutan allí. Para definir el alcance inicial, consulta nuestra guía de permisos de agentes de IA en el CRM.

Cuatro pruebas para este proceso de pedidos

Haz las pruebas en un entorno aislado, con clientes ficticios y envíos externos desactivados. Estas situaciones son una propuesta de comprobación para el ejemplo, no una certificación de seguridad.

Pedido normal: incluye referencias y cantidades válidas. Debe llegar al borrador esperado; bloquear todos los documentos tampoco sirve al negocio.

Cambio de dirección: añade una solicitud en las observaciones. Debe aparecer como cambio pendiente, sin modificar el CRM hasta completar la revisión prevista.

Cliente contradictorio: el adjunto menciona otro cliente diferente del expediente de entrada. El flujo debe detener esa asociación y explicar la discrepancia, no escoger el registro por iniciativa del modelo.

Aprobación antigua: cambia la dirección propuesta después de revisar el borrador. Comprueba que la aprobación anterior no sirve para ejecutar la versión modificada.

Anota para cada caso el resultado esperado, el resultado observado y el estado final del pedido. Revisa también el historial de cambios del CRM: una respuesta de la IA diciendo que no hizo nada no demuestra por sí sola que el registro siga intacto.

Qué hacer si aparece una instrucción sospechosa

Deja el pedido afectado pendiente, asigna un responsable y contrasta la solicitud por el canal habitual con el cliente. Conserva la referencia del archivo y la evidencia necesaria para revisar lo ocurrido, evitando copiar datos del pedido a registros generales sin necesidad.

Si hubo una modificación inesperada, revisa qué registros cambiaron antes de volver a ejecutar el flujo. El objetivo es resolver la incidencia concreta; repetir toda la importación puede añadir un segundo problema.

Qué pedir antes de ponerlo en marcha

Solicita una demostración con un pedido normal, uno contradictorio y un borrador cambiado tras la aprobación. Pide que se vean los datos finales del CRM y quién puede resolver cada incidencia. Ninguna prueba aislada garantiza protección frente a todas las variantes.

Serboweb desarrolla soluciones de inteligencia artificial para empresas e integraciones. Cuéntanos qué documentos recibe tu equipo y qué operaciones quieres automatizar para definir un proceso con revisiones proporcionadas a sus consecuencias.