Un proyecto de IA suele empezar con una pregunta aparentemente simple: «¿qué información le damos?». La respuesta no debería ser «todo lo que haya en el CRM, el ERP o las carpetas compartidas». Antes de conectar un asistente, un agente o una automatización a los sistemas de la empresa, conviene decidir qué datos necesita para una tarea concreta, bajo qué condiciones puede consultarlos y qué nunca debe recibir.
La clasificación no es una etiqueta decorativa. Sirve para transformar una idea genérica de IA en reglas aplicables: qué fuentes se autorizan, qué campos se excluyen, qué acciones requieren revisión y quién responde cuando el proceso cambia. Es una parte central de la consultoría IT y estrategia de IA cuando se quiere pasar de una prueba aislada a un uso controlado.
El problema: tratar todos los datos como si tuvieran el mismo riesgo
Un agente que prepara una respuesta comercial no necesita acceder a nóminas. Una automatización que resume incidencias de soporte no tiene por qué ver contratos completos. Y un asistente que consulta procedimientos internos no debería poder modificar registros de clientes.
Cuando se concede acceso por sistema en lugar de por finalidad, aparecen dos problemas: se expone información innecesaria y resulta difícil explicar por qué una herramienta recibió un dato o generó una acción. La alternativa es partir del proceso y limitar cada conexión al mínimo necesario.
Empieza por una tarea y una decisión, no por una herramienta
Define primero un caso de uso observable. Por ejemplo: preparar un borrador de respuesta a una consulta de cliente, clasificar correos entrantes o localizar documentación vigente para un equipo de soporte. Después, documenta qué debe entregar la IA y qué decisión seguirá siendo de una persona.
- Entrada: datos y documentos que el proceso necesita consultar.
- Salida: resumen, borrador, clasificación, propuesta o dato estructurado.
- Acción: qué puede hacer el sistema tras generar la salida.
- Responsable: quién valida una excepción, aprueba una acción o revisa un error.
Si no se puede describir la tarea sin nombrar el modelo o el proveedor, todavía falta definición de negocio. La herramienta se selecciona después de fijar el propósito, las fuentes y los límites.
Crea categorías que permitan decidir
No hace falta implantar una taxonomía compleja para empezar. Lo importante es que las categorías impliquen una regla operativa. Una pyme puede trabajar con una clasificación inicial como esta:
- Información pública: contenido publicado, catálogos o documentación disponible sin autenticación.
- Información interna: procedimientos, plantillas y conocimiento de trabajo que no debe difundirse fuera de la empresa.
- Información confidencial de negocio: precios, condiciones, previsiones, contratos, estrategias y datos de proveedores o clientes.
- Datos personales: información vinculada a personas, incluidos contactos de clientes, empleados o candidatos.
- Información especialmente restringida: credenciales, claves, secretos técnicos, datos bancarios, documentación legal sensible o cualquier conjunto que requiera un tratamiento reforzado.
La etiqueta no sustituye al análisis del caso. Un mismo documento puede contener información de varias clases. Por eso la automatización debe poder excluir campos, fragmentos o adjuntos concretos, no limitarse a aceptar o rechazar carpetas enteras.
Relaciona cada categoría con un uso permitido
Para cada clase, deja por escrito si la IA puede recibir el contenido, si puede conservarlo en una base de conocimiento, si puede enviarlo a un proveedor externo y si puede utilizarlo para ejecutar una acción. Una regla útil es distinguir entre consultar, resumir, proponer y actuar: cada verbo exige un nivel de control diferente.
Por ejemplo, una automatización puede consultar una ficha de cliente para preparar un borrador, pero no modificar un límite de crédito ni enviar una comunicación sin comprobaciones. Así se evita convertir una capacidad de lectura en permiso de decisión.
Construye una matriz de datos, finalidad y controles
Convierte la clasificación en un inventario breve por caso de uso. No hace falta empezar con todos los sistemas de la organización. Basta con cubrir el proceso que se va a poner en marcha y revisar el inventario cuando cambie.
| Elemento | Pregunta que debe responder |
|---|---|
| Finalidad | ¿Para qué tarea concreta se necesita este dato? |
| Fuente | ¿De qué sistema, carpeta o formulario procede? |
| Clase | ¿Es público, interno, confidencial, personal o restringido? |
| Acceso | ¿El agente consulta el dato completo, un campo o una versión filtrada? |
| Tratamiento | ¿Puede resumirlo, extraerlo, clasificarlo o solo señalar dónde está? |
| Salida | ¿Quién recibe el resultado y dónde queda registrado? |
| Control | ¿Qué validación, aprobación o bloqueo aplica? |
Esta matriz permite detectar una señal habitual de diseño débil: datos que se incluyen «por si acaso». Si no hay una finalidad concreta y una salida esperada, no deberían formar parte de la conexión.
Diseña barreras antes de dar acceso
Clasificar no basta si la integración entrega más información de la permitida. Los controles deben aplicarse en el punto donde el agente consulta, procesa o entrega datos.
- Usa cuentas técnicas separadas para cada automatización y limita sus permisos a la tarea definida.
- Filtra campos y adjuntos antes de que lleguen al modelo; no delegues la exclusión de datos sensibles en una instrucción escrita en el prompt.
- Separa entornos de prueba y producción, con datos de prueba apropiados para validar el flujo.
- Registra qué fuente se consultó, qué versión estaba vigente y qué salida se generó cuando el proceso tenga impacto operativo.
- Exige aprobación humana antes de enviar comunicaciones externas, modificar registros o desencadenar acciones con consecuencias económicas, legales o de acceso.
Los permisos y los límites de acción merecen el mismo cuidado que las fuentes. Un agente con información mínima pero capacidad de ejecutar cambios amplios sigue siendo un riesgo de diseño.
Decide cuándo el caso necesita una revisión adicional
Algunos usos requieren profundizar antes de construir la integración. No es una señal de que el proyecto deba detenerse; es un criterio para ajustar el alcance y los controles.
Eleva el caso a revisión de IT, seguridad, privacidad o la dirección responsable cuando se combinen datos personales, información confidencial de negocio, decisiones sobre personas, acciones irreversibles, integraciones con privilegios amplios o dependencia de información cuya vigencia no esté controlada.
Evita dos errores frecuentes
El primero es prohibir de forma genérica cualquier uso de IA con datos internos. Esa regla empuja a los equipos a buscar alternativas sin control y no ayuda a decidir qué sí puede hacerse de forma segura.
El segundo es aprobar una herramienta de forma genérica. La autorización debe estar ligada a un caso de uso, unas fuentes y unas acciones concretas. Cuando cambian esos elementos, hay que volver a revisar la decisión.
Prueba el flujo con casos que intenten salirse de la regla
Antes de activar un agente, prepara ejemplos que representen el trabajo normal y los límites. Incluye documentos incompletos, solicitudes ambiguas, contenido fuera de alcance, adjuntos restringidos y peticiones que intenten inducir una acción no permitida.
Comprueba que el sistema hace lo esperado: recupera solo las fuentes autorizadas, no expone campos excluidos, indica incertidumbre cuando falta información y deriva a una persona cuando no puede aplicar una regla. Guarda los resultados de estas pruebas junto con la versión de la configuración y de las fuentes.
Mantén la clasificación como parte del cambio operativo
La matriz queda obsoleta si cambia el proceso y nadie la revisa. Establece disparadores claros: una nueva fuente de datos, un nuevo proveedor, una ampliación de permisos, una acción automatizada adicional, un cambio relevante en el tipo de usuarios o una incidencia que revele un acceso no previsto.
Revisar estos cambios no tiene por qué convertirse en burocracia. Un expediente breve con la finalidad, la fuente, la clasificación, el responsable y las pruebas realizadas permite tomar decisiones rápidas y conservar una explicación útil.
Un punto de partida realista para una pyme
Elige un único proceso de bajo impacto, limita la entrada a una fuente conocida y define una salida que una persona pueda revisar. Cuando esa primera automatización funcione con trazabilidad, será más sencillo ampliar el alcance sin repetir errores.
Si necesitas ordenar los casos de uso, las fuentes y los controles antes de conectar IA a tus aplicaciones, cuéntanos qué proceso quieres mejorar. El objetivo no es clasificar documentos por clasificar: es permitir automatizaciones útiles con límites que el negocio, IT y seguridad puedan entender y mantener.