Conectar un asistente de IA a los datos de la empresa es una decisión de permisos, no el despliegue de un producto. Parta de la premisa de que todo lo que el asistente pueda leer, podrá extraerlo cualquiera que pueda hablar con él, y todo lo que el asistente pueda hacer, podrá desencadenarlo cualquiera que pueda influir en su entrada. Antes de empezar el piloto, deje cerradas cinco cuestiones: qué datos se permiten, qué puede hacer el asistente, quién puede usarlo, qué se registra y quién asume el riesgo.
Una nota sobre la atribución. Los puntos tomados de OWASP o NIST se indican como tales y llevan su enlace. Todo lo demás en esta lista de control es recomendación propia, no un requisito de ninguno de los dos organismos.
Decida qué datos pueden entrar
Empiece por la clasificación, porque todos los controles posteriores dependen de ella. Si no dispone de un esquema, basta con uno de tres niveles para empezar, y debe estar documentado por escrito antes de que nadie conecte un buzón de correo, un recurso compartido de archivos o un CRM.
| Nivel | Contenido típico | Regla para el asistente |
|---|---|---|
| Público | Texto publicado del sitio web, fichas de producto | Permitido |
| Interno | Políticas, notas de proyecto, wikis internas | Permitido solo en herramientas aprobadas |
| Restringido | Datos personales, contratos, credenciales, código fuente, registros financieros | Excluido hasta que un responsable designado lo autorice |
Hay dos puntos en los que los equipos suelen tropezar. En primer lugar, los conectores normalmente ingieren repositorios o unidades completos, de modo que una carpeta que nadie recuerda haber compartido acaba indexada. Depure los recursos compartidos antes de conectar, no después. En segundo lugar, los secretos incrustados en documentos (claves de API en páginas de la wiki, contraseñas en tickets) convierten una función de búsqueda en una fuga de credenciales.
Asuma que el asistente leerá texto hostil
Trate todo lo que el asistente lee (correo entrante, páginas web, documentos compartidos, archivos subidos) como contenido que otra persona puede haber escrito para manipularlo. Recomendamos diseñar el despliegue de forma que esto no cause daño, en lugar de hacer del system prompt su único control.
En la práctica:
- Dé al asistente las herramientas mínimas que necesite. Primero, acceso de solo lectura.
- Exija confirmación humana para cualquier acción con efectos secundarios: enviar correos, modificar registros, ejecutar código, realizar pagos.
- Mantenga el contenido no confiable alejado de los asistentes que además tienen acceso a datos restringidos.
- Trate la salida del asistente como una entrada no confiable para lo que sea que la consuma. Si un sistema posterior la ejecuta o la renderiza, valídela como validaría la entrada de un usuario.
Como lista de referencia de riesgos de las aplicaciones basadas en LLM, utilice el OWASP Top 10 for Large Language Model Applications. La página del proyecto describe el OWASP GenAI Security Project como una iniciativa global de código abierto que abarca los riesgos de seguridad de la IA generativa, incluidos los LLM, los sistemas de IA agéntica y las aplicaciones impulsadas por IA. Indica que el Top 10 sigue siendo un componente central y menciona una versión de 2025. La página remite a genai.owasp.org/llm-top-10/ para consultar la lista más reciente. Lea esa lista y utilice sus categorías como estructura de su modelo de amenazas en lugar de inventarse una propia.
Control de acceso y registro
El asistente debe actuar con los permisos de la persona que formula la consulta, no con una cuenta de servicio amplia. Si utiliza una única identidad compartida con acceso a todo, un empleado junior podría obtener documentos del consejo de administración con solo formular bien una pregunta. Compruebe cómo gestiona el conector los permisos por usuario y pruébelo con dos cuentas de distinta jerarquía antes de la puesta en producción.
A continuación, decida qué registrar. Como mínimo, necesita lo suficiente para reconstruir un incidente:
timestamp, user id, assistant/tool name,
source documents retrieved, actions requested,
actions executed, confirmation (yes/no), result statusDecida de antemano durante cuánto tiempo conservará estos registros, quién puede leerlos y si los propios prompts contienen datos personales. Los registros de conversaciones son un almacén de datos por derecho propio y requieren la misma clasificación que el contenido que albergan. Envíelos a quien se encargue de su monitorización, para que se detecte un volumen inusual de recuperaciones desde una misma cuenta.
Revise al proveedor antes de firmar el contrato
Haga preguntas directas al proveedor y obtenga las respuestas por escrito:
- ¿Se utilizan nuestros prompts y documentos para entrenar o mejorar modelos? ¿Puede desactivarse por contrato, y no solo mediante un ajuste de configuración?
- ¿Dónde se procesan y almacenan los datos, y qué subencargados del tratamiento intervienen?
- ¿Durante cuánto tiempo se conservan los prompts, las salidas y los archivos subidos, y podemos eliminarlos?
- ¿Qué controles de administración existen: single sign-on, acceso basado en roles, exportación de auditoría, listas de conectores permitidos?
- ¿Cómo se notifican los incidentes de seguridad y en qué plazo?
Compruebe que las respuestas coinciden con la consola de administración real. Una página de políticas y un ajuste configurable no son lo mismo. Si la herramienta ofrece plug-ins o conectores de terceros, revíselos como proveedores independientes.
Asigne un responsable al riesgo
La gobernanza suena a papeleo, y lo es, pero es lo que evita los despliegues en la sombra. El NIST AI RMF Playbook ofrece acciones sugeridas alineadas con las cuatro funciones del AI Risk Management Framework: Govern, Map, Measure y Manage. NIST afirma que el Playbook no es una lista de control ni un conjunto de pasos que deban seguirse íntegramente, y que sus sugerencias son voluntarias. Añade también que el AI RMF 1.0 se está actualizando y que el Playbook le seguirá, por lo que conviene comprobar cuál es la versión vigente. Tome lo que encaje con una empresa de su tamaño.
Nuestra recomendación es llevar un registro breve de todas las herramientas de IA en uso, cada una con un responsable, los niveles de datos que puede tocar y una fecha de revisión. Añada una columna más: si el departamento jurídico ha confirmado que las obligaciones del EU AI Act o del RGPD se aplican a ese caso de uso, y qué conclusión alcanzó. Aquí no hemos evaluado esas obligaciones, así que pida a su asesoría jurídica o a un asesor de cumplimiento que lo determine. Si desea ayuda para montar el registro y el proceso de revisión, nuestro servicio de consultoría incluye evaluaciones de preparación.
Por dónde empezar
- Haga un inventario de todos los asistentes de IA que ya se utilizan, incluidas las cuentas gratuitas que los empleados se hayan creado por su cuenta, y designe un responsable para cada uno.
- Redacte la clasificación de tres niveles anterior y marque a qué nivel pertenece cada fuente de datos conectada. Retire del alcance las fuentes restringidas.
- Ejecute un piloto con acceso de solo lectura, permisos por usuario y confirmación humana para cada acción. Pruébelo con dos cuentas de distinta jerarquía.
- Active el registro, fije un periodo de retención y envíe los logs a quien monitorice sus sistemas.
- Envíe las preguntas al proveedor, conserve las respuestas escritas junto con el contrato y pida al departamento jurídico que confirme si se aplican las obligaciones del EU AI Act o del RGPD.
- Antes de un despliegue más amplio, haga que alguien que intente atacarlo pruebe la configuración. Una prueba de penetración con escenarios construidos en torno a sus conectores reales muestra lo que un modelo de amenazas sobre el papel pasa por alto.
