Qué revisar antes de enviar datos sensibles a una IA

Un marco práctico para clasificar información, revisar proveedores, limitar permisos y decidir qué datos pueden entrar en una herramienta o agente de IA.

Copiar un texto en un chat de IA parece una acción aislada. En una empresa puede iniciar un recorrido más largo: el prompt sale de un equipo, viaja a un proveedor, queda registrado, activa herramientas conectadas y termina dentro de otro sistema. Cuando además hay archivos, CRM, correo o bases internas, la pregunta deja de ser qué escribió una persona y pasa a ser cómo circula la información.

El objetivo no es prohibir datos de manera genérica ni asumir que toda herramienta los usa del mismo modo. Es decidir con evidencia qué información necesita cada caso, qué configuración aplica, quién puede acceder y qué ocurre después. Las respuestas cambian entre proveedores, productos, planes y contratos; por eso conviene verificarlas antes de integrar.

Esta guía propone controles operativos para una PyME. No reemplaza una evaluación legal, de privacidad o seguridad específica, y no atribuye prácticas no verificadas a ninguna empresa.

Primero: clasificar la información

Sin una clasificación mínima, la regla suele ser “usar con cuidado”. Es demasiado ambigua para orientar a un equipo o configurar una automatización. Una clasificación simple permite traducir sensibilidad en permisos y controles.

Pública: información publicada y aprobada para circulación abierta.
Interna: procedimientos, borradores y conversaciones cuyo impacto de exposición es acotado.
Confidencial comercial: precios, márgenes, contratos, estrategia, credenciales, código o propiedad intelectual.
Personal: datos que identifican o pueden identificar a clientes, empleados, proveedores u otras personas.
Restringida: información cuyo uso o exposición puede generar daño relevante, obligación regulatoria o riesgo de seguridad.

Las categorías exactas dependen de la organización. Lo importante es que sean pocas, entendibles y accionables. Cada una debería indicar si puede usarse, bajo qué herramienta, con qué transformación y quién puede autorizar una excepción.

Datos personales y datos comerciales no son el mismo problema

Los datos personales exigen considerar finalidad, base aplicable, transparencia, minimización y derechos según la jurisdicción. Los datos comerciales sensibles pueden no identificar personas y aun así exponer una negociación, una ventaja competitiva o una credencial. Un mismo archivo puede contener ambas cosas.

Eliminar nombre y correo no siempre anonimiza. Un número de cliente, una descripción muy específica o la combinación de atributos puede volver identificable a alguien. Cuando el caso no necesita identidad, conviene reducir campos antes de enviar y trabajar con ejemplos sintéticos o datos enmascarados durante pruebas.

Prompts y archivos también son datos

Un prompt puede revelar más que su respuesta: nombres de clientes, incidentes, instrucciones internas, objetivos comerciales o fragmentos de código. Un archivo puede incluir hojas ocultas, comentarios, historial, metadatos o pestañas que la persona no pretendía compartir.

Antes de habilitar cargas, la empresa debería definir formatos admitidos, tamaño, clasificación permitida, escaneo, extracción y borrado. Si el flujo sólo necesita tres campos de una planilla, enviar el archivo completo aumenta superficie sin mejorar el resultado.

El proveedor visible no es toda la cadena

Una solución puede combinar interfaz, modelo, almacenamiento, base vectorial, automatizador, observabilidad y CRM. Cada componente puede recibir una parte del dato. El mapa útil no pregunta sólo qué modelo se usa, sino qué sistemas tocan la información desde el ingreso hasta el resultado.

Listar proveedor, producto, plan y región relevante.
Revisar términos, retención, uso para entrenamiento y opciones de exclusión disponibles.
Identificar integraciones, trackers, logs y subprocesadores que formen parte del recorrido.
Confirmar mecanismos de eliminación, exportación y respuesta ante incidentes.
Registrar cambios de configuración o versión que puedan modificar el tratamiento.

No todas las respuestas se encuentran en una página comercial. Cuando el caso tiene impacto, puede requerir documentación técnica, acuerdo de tratamiento, revisión de seguridad y consulta especializada. Si una condición central no puede verificarse, el diseño debería reducir datos o elegir otra alternativa.

Permisos y acceso interno

Una herramienta segura puede quedar mal configurada. Las cuentas compartidas, tokens con acceso amplio y conectores que leen toda una carpeta convierten un caso pequeño en un riesgo grande. El principio práctico es mínimo privilegio: cada persona y servicio accede sólo a lo necesario para su función.

Conviene separar ambientes de prueba y producción, usar identidades individuales, rotar secretos y retirar accesos cuando cambia un rol. Los agentes requieren especial atención porque pueden actuar, no sólo responder: leer datos, enviar mensajes o modificar registros debería depender de permisos explícitos y observables.

Retención y logs: guardar también es una decisión

Los logs ayudan a diagnosticar, auditar y mejorar, pero pueden duplicar prompts, respuestas y datos sensibles. Guardar todo por tiempo indefinido no equivale a tener trazabilidad. La política debería definir qué evento se registra, con qué detalle, por cuánto tiempo, quién accede y cómo se elimina.

En muchos flujos alcanza con conservar identificadores, estados, tiempos, versión y resultado de validación, evitando copiar el contenido completo. En otros, la evidencia del dato de entrada es necesaria. La decisión debe responder al impacto y a la obligación concreta, no a la capacidad técnica de almacenar.

Cuándo tiene sentido una validación humana

Una persona debería intervenir cuando el costo del error es alto, la decisión es difícil de revertir, la información es ambigua o el resultado afecta a terceros. Pero agregar un botón de aprobación no resuelve por sí mismo el riesgo. La revisión necesita mostrar datos relevantes, origen, confianza, excepción detectada y acción disponible.

Para tareas repetitivas y de bajo impacto, pueden bastar reglas automáticas, muestreo y alertas. Para comunicaciones sensibles, cambios financieros, permisos o decisiones sobre personas, la validación debería ser más fuerte. El criterio es proporcionalidad.

Un control mínimo viable para una PyME

Nombrar un dueño del caso de uso y describir su objetivo.
Definir datos permitidos, prohibidos y transformaciones previas.
Documentar proveedor, plan, retención, entrenamiento e integraciones.
Configurar acceso mínimo y separar pruebas de producción.
Registrar eventos necesarios sin duplicar contenido sensible por defecto.
Establecer validaciones, excepciones y un mecanismo de apagado.
Capacitar al equipo con ejemplos concretos, no sólo con una política general.
Revisar el flujo cuando cambian proveedor, datos, alcance o impacto.

El criterio NexOps es diseñar el recorrido del dato antes de escalar el agente. Una solución útil no necesita conocer toda la empresa: necesita entradas delimitadas, permisos mínimos, estados visibles y una salida controlada. Cuanto mejor definido está el proceso, menos información innecesaria circula y más fácil resulta detectar una excepción.

Ver más novedades de NexOps