La seguridad de un proyecto de inteligencia artificial no se resuelve con una sola configuración ni con elegir un proveedor conocido. Depende del flujo completo: qué información entra, quién puede verla, dónde se procesa, qué queda registrado, qué acción produce la respuesta y cómo se corrige una excepción.
Por eso conviene analizar la IA como parte de la arquitectura empresarial. Un asistente interno, un proceso de OCR y un chatbot público pueden utilizar modelos similares, pero exponen datos y generan riesgos distintos.
1. Definir el propósito antes de enviar datos a un modelo
El primer control es funcional. La empresa debe poder explicar qué tarea realizará la IA, qué decisión apoyará y qué información necesita realmente para hacerlo. Si el objetivo es ambiguo, resulta difícil justificar los datos utilizados o evaluar si la respuesta es adecuada.
Una clasificación operativa —no necesariamente jurídica— ayuda a discutir el alcance con responsables de negocio, tecnología y privacidad:
- Información pública: contenido que la empresa ya publica y puede reutilizar sin revelar contexto interno.
- Información interna: procedimientos, catálogos o conocimiento destinado a usuarios de la organización.
- Información confidencial: precios negociados, contratos, antecedentes comerciales, datos personales o documentos de clientes y proveedores.
- Información de alto impacto: datos cuya exposición o uso incorrecto podría afectar derechos, continuidad operacional o decisiones relevantes.
No todo dato disponible debe incorporarse. Minimizar campos, ocultar identificadores cuando no son necesarios y separar las pruebas de la información productiva reduce exposición, aunque no elimina por completo el riesgo.
2. Dibujar el recorrido completo de la información
Antes de implementar, conviene representar el flujo desde la fuente hasta la acción final. Un diagrama sencillo suele revelar dependencias que no aparecen al evaluar únicamente el modelo.
- Origen: correo, formulario, documento, CRM, ERP, base de conocimiento o aplicación móvil.
- Preparación: extracción, limpieza, fragmentación, anonimización o incorporación de instrucciones.
- Procesamiento: servicio de IA, región, cuenta empresarial y componentes intermedios.
- Destino: respuesta al usuario, registro en un sistema, tarea, alerta, borrador o acción automática.
- Persistencia: archivos, prompts, resultados, copias de respaldo, caché y registros técnicos.
- Acceso: usuarios, administradores, equipo de soporte y proveedores que podrían intervenir.
También hay que distinguir entre una herramienta de consumo, una cuenta empresarial y una integración por API. Sus condiciones de uso, controles administrativos y opciones de retención pueden ser diferentes y deben revisarse para la configuración concreta contratada.
3. Revisar al proveedor y la configuración, no solo la marca
Las respuestas deben quedar documentadas para el servicio y plan que se utilizarán. Entre las preguntas mínimas están:
- ¿El proveedor utiliza entradas o salidas para entrenar o mejorar modelos? ¿Existe una opción contractual o técnica para excluirlas?
- ¿En qué regiones se procesan y almacenan los datos?
- ¿Qué plazos de retención aplican a solicitudes, archivos y registros?
- ¿Cómo se eliminan los datos y qué ocurre con respaldos o registros de seguridad?
- ¿Qué subprocesadores participan y cómo se notifican los cambios?
- ¿Qué controles de acceso, auditoría y administración ofrece la cuenta contratada?
- ¿Qué mecanismos existen para reportar incidentes o revocar credenciales?
Las respuestas comerciales no reemplazan una revisión técnica, contractual y, cuando corresponde, legal. Además, pueden cambiar con el tiempo; por eso deberían formar parte de la revisión periódica del proyecto.
4. Aplicar mínimo privilegio y separar ambientes
La identidad que ejecuta una integración debería acceder solo a los datos y acciones necesarios. Si una automatización únicamente crea un borrador en el CRM, no necesita permisos para eliminar clientes ni modificar configuraciones generales.
En la práctica, esto implica separar desarrollo, pruebas y producción; utilizar cuentas de servicio identificables; custodiar secretos fuera del código; rotar credenciales; limitar permisos por sistema y mantener un procedimiento de baja. En una integración con Google Workspace, por ejemplo, los alcances autorizados deberían corresponder a la función que el usuario activó.
5. Diseñar trazabilidad sin convertir los logs en otra fuga
Los registros ayudan a investigar errores, medir calidad y reconstruir una acción. Sin embargo, guardar prompts y documentos completos de manera indiscriminada puede duplicar información sensible en herramientas de monitoreo.
Una política de trazabilidad útil define qué se registra, para qué se conserva, quién puede consultarlo y cuándo se elimina. Según el caso, puede bastar con guardar identificadores, versión del flujo, usuario, fecha, estado, regla aplicada y referencia al documento original, en lugar de copiar todo su contenido.
6. Adaptar los controles al tipo de solución
OCR y documentos. Hay que controlar los archivos de origen, los campos extraídos, la confianza de cada dato y la validación previa a escribir en el ERP. Una cifra mal interpretada no debería transformarse automáticamente en un documento definitivo si el proceso exige revisión.
Asistentes con búsqueda interna. El buscador debe respetar permisos en el momento de la consulta. Indexar documentos con acceso restringido y mostrarlos después a cualquier usuario anula el control del repositorio original.
Chatbots externos. Conviene limitar las fuentes, separar información pública de datos de clientes y probar intentos de manipular instrucciones o extraer contenido interno. La derivación a una persona debe estar prevista cuando la identidad, el contexto o la respuesta no sean suficientes.
Agentes y automatizaciones. Cuanto mayor sea la capacidad de actuar, mayor debe ser el control. Validación de datos, listas de acciones permitidas, límites, confirmación humana, idempotencia y mecanismos para detener el flujo son más importantes que la fluidez de una demostración.
7. Mantener reglas determinísticas alrededor del modelo
Un modelo puede clasificar, resumir o proponer. Las reglas críticas —formatos, montos permitidos, estados, permisos, duplicados y obligatoriedad de campos— deberían validarse mediante lógica controlada antes de afectar un sistema empresarial.
También conviene definir qué sucede cuando el modelo no responde, entrega una salida inválida o cambia su comportamiento. Reintentos acotados, colas, estados de error y revisión manual evitan que una falla silenciosa se propague hacia el CRM, el ERP o la atención al cliente.
Checklist para autorizar un piloto
- El propósito, responsable y usuarios autorizados están identificados.
- Existe un inventario de fuentes, campos, destinos y acciones.
- Las pruebas utilizan datos sintéticos o minimizados cuando es posible.
- Se revisaron condiciones del proveedor, retención y configuración de la cuenta.
- Los permisos están limitados y los secretos no quedan incorporados en el código.
- Las salidas se validan antes de ejecutar acciones relevantes.
- Hay criterios de calidad, casos adversos y un responsable de aceptar el resultado.
- Se definieron logs, alertas, eliminación de datos y respuesta ante incidentes.
- Existe una alternativa operativa si el servicio de IA no está disponible.
Cuándo un piloto puede avanzar a producción
No basta con que una demostración funcione. El equipo debería conocer los errores observados, el impacto aceptable, los casos que requieren revisión, los costos operativos y el mecanismo de soporte. La decisión de avanzar depende de la criticidad del proceso y del control que la empresa necesita, no de una tasa universal aplicable a todos los proyectos.
En Tecnich abordamos estas iniciativas como una combinación de inteligencia artificial aplicada, integración y automatización de procesos. Si necesitas mapear un caso, delimitar sus datos y diseñar una primera etapa verificable, puedes contactarnos.