Inicio/Blog/Seguridad y gobernanza de IA

Seguridad de IA: cómo revisar una integración nueva

La prueba útil empieza en el recorrido que la integración modifica

Revisión ejecutiva de una integración de inteligencia artificial con datos y permisos controlados

Comparte esta publicación

WhatsApp Facebook LinkedIn X Telegram

Una integración de IA suele entrar a la empresa con una promesa concreta: consultar documentos, clasificar solicitudes, resumir conversaciones o preparar una respuesta. El riesgo aparece cuando se revisa solamente la función visible y se deja fuera el recorrido completo. Para responder, la integración puede leer más datos de los necesarios, heredar permisos demasiado amplios, llamar a otra herramienta o producir una salida que alguien toma como confirmada.

La dirección no necesita revisar cada detalle del modelo para tomar una primera decisión. Sí necesita saber qué información entra, qué puede consultar la solución, qué acciones puede preparar o ejecutar, quién revisa los casos dudosos y cómo se detiene el flujo si algo sale mal. Esa revisión convierte una demostración atractiva en una decisión operativa.

Empiece por el cambio en el trabajo

Antes de preguntar qué modelo utiliza el proveedor, describa el recorrido que la integración va a modificar. Una herramienta conectada al correo no tiene el mismo riesgo que una que consulta expedientes, actualiza un CRM o envía confirmaciones a clientes.

Escriba una frase sencilla: “la integración recibirá solicitudes de soporte, consultará la base aprobada y preparará una respuesta para revisión”. Si la frase necesita agregar acceso a clientes, documentos históricos, facturación y acciones externas, el alcance ya es mayor de lo que parecía en la demo.

La revisión debe identificar cuatro puntos:

  • qué evento inicia el proceso;
  • qué fuentes consulta la IA;
  • qué sistemas puede leer o modificar;
  • qué recibe la persona que debe decidir.

El AI Risk Management Framework de NIST plantea que el riesgo también puede surgir de sistemas, datos y componentes de terceros cuando se integran sin suficiente gobierno interno. La pregunta práctica para la empresa es quién conserva la responsabilidad cuando una respuesta depende de varios proveedores.

La conexión no debe recibir acceso por comodidad

Una integración nueva suele pedir acceso a una fuente existente porque así se implementa más rápido. Esa facilidad puede ocultar una diferencia entre lo que el proceso necesita y todo lo que la cuenta permite consultar.

Si el asistente debe responder sobre el estado de una solicitud, probablemente no necesita leer el expediente completo ni todas las conversaciones anteriores. Si debe clasificar correos, quizá no necesita enviar mensajes ni cambiar el estado del caso. Separar lectura, preparación y ejecución reduce el alcance de un error.

Conviene revisar cada permiso con una pregunta concreta: ¿qué tarea exige este acceso y qué ocurre si se retira? Un permiso que nadie puede explicar debería quedar fuera de la primera prueba. También debe estar claro si el acceso pertenece a una persona, a una cuenta técnica o al proveedor, y cómo se revoca cuando cambia el proyecto.

En la página de seguridad y gobernanza de IA de Global Agenttic se agrupan estos criterios alrededor de permisos, datos, privacidad y trazabilidad. Para una dirección, la señal de madurez no es que la integración pueda conectarse a todo. Es que el proveedor pueda explicar por qué cada conexión existe y cómo se puede retirar sin apagar una operación completa.

Revise el camino de los datos

La pregunta “¿dónde se procesa la información?” es necesaria, pero no suficiente. Hay que seguir el dato desde la entrada hasta su eliminación o conservación.

Pregunte qué ocurre con los documentos enviados, los registros de conversación, las instrucciones, los resultados intermedios y los errores. La integración puede enviar datos a un modelo, a un sistema de búsqueda, a una herramienta de monitoreo y a un canal de notificación. Cada salto necesita una finalidad entendible, una regla de acceso y un responsable.

La prueba inicial debería usar datos sintéticos o una muestra reducida cuando el proceso lo permita. Después se pueden incorporar casos reales, empezando por la información menos sensible. Esta secuencia permite observar qué campos son realmente necesarios y cuáles llegaron a la integración porque estaban disponibles, no porque hicieran falta.

También conviene acordar qué significa retirar un dato. Borrar el archivo original no demuestra que desaparecieron las copias, los índices, las exportaciones o los registros de prueba. El perfil de IA generativa de NIST señala los riesgos de integraciones de componentes y proveedores que no son transparentes o trazables. La empresa debe pedir una respuesta verificable sobre el tratamiento de sus datos, sin conformarse con una descripción general del servicio.

Pruebe instrucciones maliciosas y solicitudes fuera de alcance

Una integración que consulta contenido externo puede recibir instrucciones dentro de ese contenido. Un correo, archivo o página puede intentar cambiar el comportamiento del asistente, pedir información que no corresponde o inducirlo a llamar una herramienta. Esto puede ocurrir aunque el usuario interno no haya escrito una instrucción peligrosa.

El OWASP Top 10 para aplicaciones con modelos de lenguaje identifica la inyección de instrucciones y la agencia excesiva entre los riesgos que deben considerarse en estas aplicaciones. Para una evaluación empresarial, no hace falta convertir la prueba en un ejercicio de laboratorio. Basta con preparar casos que representen el trabajo real:

  • un documento que contiene una instrucción distinta de la solicitud del usuario;
  • una petición de datos pertenecientes a otra área;
  • un mensaje que pide enviar, borrar o modificar algo sin autorización;
  • una fuente que contradice la política vigente;
  • una solicitud cuyo contexto no alcanza para responder con seguridad.

La salida esperada no siempre es una respuesta. Puede ser una pregunta de aclaración, una negativa explicada, una tarea para revisión humana o una pausa del proceso. Si la integración responde con seguridad fingida ante estos casos, todavía no está lista para ampliar su alcance.

Separe una recomendación de una acción

Una respuesta generada puede parecer correcta y aun así no tener autoridad para cambiar un registro, confirmar un precio o comprometer una fecha. La integración debe distinguir entre informar, preparar y actuar.

En una primera fase, la IA puede clasificar la solicitud, reunir evidencia y preparar un borrador. La persona responsable confirma el contenido y decide si se registra, se envía o se ejecuta una acción. Ese punto de revisión debe aparecer en el flujo, no quedar como una recomendación informal para que el equipo “tenga cuidado”.

La revisión humana también necesita contexto. La persona debe ver qué pidió el usuario, qué fuentes consultó la integración, qué parte de la salida es una inferencia y qué acción quedaría pendiente. Un botón de aprobar sin evidencia desplaza la responsabilidad sin ayudar a decidir.

Para ampliar la integración, primero conviene demostrar que el sistema puede mantener un límite. En inteligencia artificial aplicada el valor está en conectar la tecnología con el proceso, las fuentes y el criterio de las personas que sostienen la operación.

Pida evidencia de una semana difícil

La prueba de una integración no debería limitarse a cinco preguntas bien formuladas. Incluya días con solicitudes incompletas, cambios de versión, información contradictoria, permisos retirados y usuarios que necesitan escalar el caso.

El proveedor debería poder mostrar, sin exponer información indebida:

  • la entrada recibida y el momento en que llegó;
  • las fuentes consultadas y su versión;
  • los permisos utilizados;
  • la salida generada y la persona que la revisó;
  • los errores, pausas o acciones que no se ejecutaron;
  • la forma de corregir o revertir un resultado.

La evidencia no tiene que convertirse en un tablero enorme. Debe permitir reconstruir qué ocurrió cuando alguien pregunte por qué la integración respondió, clasificó o preparó algo de una manera determinada.

Una prueba útil también mide el trabajo que la integración agrega. Si reduce respuestas repetitivas, pero llena al equipo de excepciones sin contexto, el resultado no es una mejora. Revise el tiempo de revisión, los casos devueltos, los datos que faltaron y las ocasiones en que el usuario tuvo que empezar de nuevo.

La decisión que conviene dejar por escrito

Antes de aprobar una integración nueva, la dirección debería conservar una decisión breve con cinco elementos: proceso incluido, fuentes autorizadas, permisos otorgados, acciones que requieren aprobación y condición para pausar o retirar la conexión.

Ese registro evita que el alcance crezca por acumulación de solicitudes. También facilita comparar el resultado del piloto con lo que realmente se aprobó. Si la empresa no puede explicar qué parte del trabajo se está delegando, todavía no tiene una integración lista para producción.

La seguridad de IA se revisa en el punto donde la solución toca datos, personas y decisiones. Una conexión pequeña, con fuentes delimitadas, permisos retirables y evidencia suficiente, ofrece una base más razonable para aprender que una integración amplia aprobada por entusiasmo.

Fuentes consultadas

¿Te resultó útil este artículo?
Empecemos

¿Listo para aplicar esto en su operación?

Hagamos un diagnóstico inicial, sin compromiso.