Clasificación de datos “mínimo viable”: 4 niveles, dueños y reglas para SaaS, nube e IA

Una clasificación de datos mínima bien implantada acelera decisiones sin renunciar al control. En la práctica, eso significa que un equipo comercial deja de preguntar cada semana si puede cargar una lista en una herramienta externa, finanzas sabe qué informes requieren restricciones adicionales y RR. HH. tiene criterios claros para compartir documentación con terceros sin depender de consultas improvisadas.

También reduce costes invisibles. Cuando no existe un lenguaje común sobre sensibilidad, los datos se copian en exceso, se retienen más tiempo del necesario y terminan dispersos entre drives, correos, herramientas de colaboración, CRMs, plataformas de analítica y asistentes de IA. Esa dispersión incrementa fricción, riesgo y esfuerzo de revisión.

Para dirección, la clave es esta: la clasificación no debe convertirse en burocracia documental, sino en una forma de decidir “cómo sí” trabajar con datos. Si el modelo es simple y entendible, habilita. Si es complejo y ambiguo, se ignora. Por eso una versión mínimo viable suele ser mejor punto de partida que un marco perfecto que nadie adopta.

Acciones recomendadas

1. Definir cuatro niveles de clasificación con nombres simples, criterios comprensibles y ejemplos por área en una guía de una página.
2. Asignar dueños de datos por dominio de negocio, como clientes, finanzas, personas, operaciones o producto, con capacidad real para decidir clasificación y compartición.
3. Establecer reglas mínimas por nivel sobre almacenamiento, acceso, compartición externa, retención y uso en herramientas de IA.
4. Revisar primero los repositorios de mayor exposición, como drives compartidos, wikis, herramientas BI, CRM y espacios colaborativos con terceros.
5. Crear un circuito de excepciones con justificación, aprobador, controles compensatorios y fecha de caducidad.
6. Formar por rol, no solo de manera genérica: una persona de ventas no necesita el mismo detalle operativo que alguien de RR. HH. o administración.
7. Medir cobertura, incidencias y tiempo de decisión para ajustar reglas según fricción real y no solo según diseño teórico.

Una política extensa no sustituye una regla simple y repetible para preguntas cotidianas (compartir con un proveedor, subir un documento a un SaaS, usar IA o aprobar una excepción). Una clasificación mínima viable sirve para eso: pocos niveles, criterios enseñables y decisiones asignadas.

El principio clave: pocos niveles, ejemplos claros y responsables definidos

Hay tres errores comunes cuando una empresa aborda este tema.

El primero es diseñar demasiadas categorías: cuantas más etiquetas y subetiquetas, más interpretaciones e inconsistencia.

El segundo es hablar en abstracto: sin ejemplos concretos por área, los términos no guían decisiones.

El tercero es no definir quién decide. Sin dueño del dato, la empresa reacciona con parálisis o improvisación. La clasificación es una decisión de negocio, apoyada por TI, seguridad y compliance.

Por eso, una propuesta mínima viable necesita tres piezas inseparables:

• Pocos niveles, para que sea adoptable.
• Ejemplos claros por dominio, para reducir ambigüedad.
• Responsables definidos, para que haya decisión y trazabilidad.

Un modelo práctico de 4 niveles

El número exacto puede variar según sector o complejidad operativa, pero cuatro niveles suelen ofrecer un equilibrio razonable entre simplicidad y utilidad.

1. Público

Información que puede difundirse sin causar impacto relevante si terceros la ven. No requiere protección especial más allá de asegurar integridad y versión vigente.

Ejemplos típicos:

• Contenido web corporativo publicado.
• Material comercial ya aprobado para difusión.
• Notas de prensa.
• Documentación de producto pensada para clientes o partners.

Regla base: se puede compartir externamente siguiendo los procesos habituales, manteniendo control de edición cuando aplique.

2. Interno

Información de uso interno cuyo acceso público no sería deseable, pero cuyo impacto sería moderado. Es el nivel donde suele vivir la mayor parte de la documentación operativa.

Ejemplos típicos:

• Procedimientos internos.
• Planes de equipo.
• Wikis operativas.
• Información de proyectos sin datos sensibles.
• Métricas generales de rendimiento no confidenciales.

Regla base: acceso interno por necesidad y compartición externa solo con propósito claro y canal aprobado.

3. Confidencial

Información cuyo acceso indebido podría generar impacto significativo en clientes, empleados, finanzas, ventaja competitiva o cumplimiento. Aquí suelen aparecer muchas de las dudas operativas relevantes.

Ejemplos típicos:

• Datos de clientes no públicos.
• Información financiera no publicada.
• Documentación de RR. HH.
• Contratos con condiciones económicas.
• Hojas de ruta de producto no públicas.
• Informes de auditoría interna o evaluaciones de riesgo.

Regla base: acceso por mínimos privilegios, compartición externa controlada y revisión periódica; uso en IA solo con condiciones y herramientas aprobadas cuando proceda.

4. Restringido

Información de muy alta sensibilidad o de impacto severo si se expone, altera o comparte indebidamente. No es un cajón para “todo lo importante”; debe reservarse para aquello que realmente exige un tratamiento diferencial.

Ejemplos típicos:

• Credenciales, secretos, claves y tokens.
• Datos especialmente sensibles de personas si aplican al negocio.
• Determinados expedientes de RR. HH. o información disciplinaria.
• Segmentos de datos de clientes con alta sensibilidad.
• Claves criptográficas, copias de seguridad sin protección o configuraciones privilegiadas.

Regla base: acceso muy limitado, no compartición externa por defecto y exclusión de IA generalista salvo excepción aprobada.

Reglas mínimas por nivel: lo que realmente debe quedar definido

La clasificación solo crea valor si cada nivel activa reglas operativas. No hace falta una enciclopedia; sí una tabla clara y aplicable. Como mínimo, conviene decidir cinco dimensiones.

Almacenamiento permitido

No todos los datos deberían residir en cualquier repositorio corporativo. La pregunta no es solo “si está en la nube”, sino en qué servicio, bajo qué configuración y con qué capacidad de control.

Por ejemplo:

• Público: puede residir en plataformas de publicación y repositorios abiertos controlados.
• Interno: puede vivir en SaaS corporativo aprobado y repositorios comunes con permisos por grupo.
• Confidencial: solo en servicios aprobados con controles reforzados, trazabilidad razonable y capacidad de limitar compartición.
• Restringido: en sistemas específicamente autorizados, con segmentación y administración estricta.

Esto evita el error de tratar del mismo modo un documento interno de equipo y un archivo con credenciales o datos muy sensibles.

Compartición externa

Aquí suele estar uno de los mayores focos de incidentes cotidianos: enlaces públicos, permisos heredados, invitaciones a terceros sin caducidad o exportaciones a herramientas no revisadas.

Una regla mínima útil puede distinguir:

• Qué niveles se pueden compartir fuera de la organización.
• Con qué autorización.
• En qué canales.
• Durante cuánto tiempo.
• Con qué revisiones posteriores.

En muchos casos, “interno” puede compartirse con terceros concretos bajo necesidad de negocio y canal aprobado; “confidencial” requerirá validación adicional del responsable del dato; “restringido” debería partir de la no compartición salvo casos justificados y controlados.

Acceso

La clasificación tiene que aterrizar en permisos reales. Si no, se queda en nomenclatura. Conviene definir requisitos mínimos por nivel:

• Acceso por necesidad de negocio.
• Grupos y roles en lugar de permisos individuales cuando sea posible.
• MFA para repositorios de mayor sensibilidad.
• Revisiones periódicas de acceso, especialmente en confidencial y restringido.
• Gestión de altas, bajas y cambios coordinada con TI y responsables de área.

El objetivo no es sofisticación técnica máxima, sino evitar accesos heredados, permisos excesivos y cuentas que mantienen visibilidad de información que ya no necesitan.

Retención y borrado

Clasificar también debe servir para conservar menos y mejor. Muchas organizaciones retienen por inercia, no por decisión. Eso aumenta superficie de exposición, complejidad operativa y esfuerzo de búsqueda.

No se trata de fijar plazos universales sin validación, especialmente si existen requisitos sectoriales o contractuales. Sí de establecer que cada dominio tenga una pauta: qué se conserva, por cuánto tiempo, por qué motivo y cómo se elimina o archiva cuando deja de ser útil. Cuanto más sensible sea el dato, menos sentido tiene mantener copias dispersas sin justificación.

Uso en herramientas de IA

Este punto ya no es opcional. Aunque no exista una política madura, los equipos están probando asistentes, copilots y automatizaciones. Si la clasificación no dice nada sobre IA, la organización deja un vacío operativo.

Una pauta mínima podría ser:

• Público: uso generalmente permitido.
• Interno: permitido en herramientas aprobadas, evitando exposición innecesaria.
• Confidencial: solo en casos definidos, con herramientas autorizadas, controles contractuales o técnicos adecuados y revisión del responsable del dato cuando proceda.
• Restringido: no introducir por defecto en herramientas de IA generalistas; cualquier excepción debe estar expresamente aprobada.

La formulación exacta dependerá del entorno y de la validación con legal, seguridad y compras cuando haya terceros implicados. Lo importante es fijar una regla comprensible y no dejar la decisión al criterio individual de cada usuario.

Roles y responsabilidades: quién decide qué

Una clasificación mínima fracasa cuando se redacta como una política sin responsables claros. Conviene separar al menos tres funciones.

Dueño del dato

Es el responsable de negocio del dominio de información. No necesita conocer todos los detalles técnicos, pero sí debe decidir:

• Cómo se clasifica el dato en su contexto.
• Con quién puede compartirse.
• Qué excepciones acepta.
• Qué nivel de retención tiene sentido.
• Qué condiciones deben cumplirse para usarlo en terceros o IA.

Sin responsable del dato, nadie responde a la pregunta principal: “¿podemos hacer esto con este dato?”

Custodio o TI

Es quien habilita el entorno operativo. Su papel no es decidir la sensibilidad del dato, sino traducirla a controles:

• Configurar repositorios y permisos.
• Aplicar MFA, grupos y restricciones.
• Habilitar herramientas aprobadas.
• Desactivar comparticiones inseguras.
• Ayudar a automatizar etiquetado o revisiones cuando sea posible.

Seguridad y compliance/legal

Su rol es definir criterios, revisar excepciones y asegurar coherencia, sin convertirse en cuello de botella para cada decisión ordinaria.

Ejemplos prácticos por área y zonas grises

Ejemplos rápidos:

• Ventas: presentación publicada (público), propuesta estándar (interno), pipeline con importes/contactos (confidencial), exportaciones CRM con campos sensibles o credenciales (restringido).
• Finanzas: política de gastos (interno), cierre no publicado (confidencial), credenciales bancarias (restringido).
• RR. HH.: onboarding (interno), desempeño/contratos (confidencial), expedientes delicados (restringido).
• Producto/tecnología: arquitectura general (interno), hoja de ruta no anunciada (confidencial), claves/tokens (restringido).

Habrá zonas grises: datos anonimizados que bajan de sensibilidad o documentos que suben de nivel al incorporar información no pública. El objetivo no es eliminar el juicio humano, sino reducirlo a los casos que de verdad lo requieren.

Un camino rápido para equipos: 5 preguntas antes de compartir o subir un dato

Para evitar consultas permanentes, conviene ofrecer un árbol de decisión simple. No sustituye el criterio del responsable del dato, pero guía casos habituales.

1. ¿La información ya es pública o está pensada para ser difundida fuera de la empresa?
2. Si se expusiera por error, ¿causaría impacto relevante a clientes, empleados, finanzas o ventaja competitiva?
3. ¿Incluye datos de personas, condiciones contractuales, información financiera no pública, código sensible o detalles operativos de riesgo?
4. ¿Contiene secretos, credenciales o elementos cuya exposición tendría impacto severo?
5. ¿La herramienta o tercero donde se quiere usar está aprobado para ese nivel de información?

Si la respuesta a la cuarta pregunta es sí, normalmente estamos en restringido. Si no llega a ese nivel pero la exposición causaría daño significativo, suele ser confidencial. Si no es pública pero su impacto sería moderado, probablemente es interna. Este tipo de guía acelera mucho más que una política larga.

Implantación en 30, 60 y 90 días

No hace falta esperar a una plataforma perfecta de data governance. Una versión útil puede lanzarse en fases cortas.

Primeros 30 días

Acordar los cuatro niveles, redactar criterios simples y recopilar ejemplos por área. Nombrar responsables por dominios principales y publicar una política breve, idealmente de una o dos páginas más una “chuleta” visual. También conviene definir ya la regla mínima de uso en IA y el proceso de excepción.

A 60 días

Aplicar etiquetado ligero en repositorios críticos, aunque sea inicialmente manual o por convenciones simples. Priorizar drives, CRM, espacios colaborativos, BI, sistemas de tickets y documentación compartida. Formar a mandos, responsables y usuarios frecuentes de herramientas externas o IA.

A 90 días

Introducir controles graduales: revisión de compartición externa, recertificación de permisos en repositorios sensibles, grupos de acceso más ordenados y seguimiento de excepciones con caducidad. En paralelo, revisar fricciones reales: dónde la clasificación ayuda y dónde complica sin aportar valor.

Métricas que sí ayudan a mejorar

No hace falta medir decenas de variables. Bastan unos indicadores que conecten con adopción y reducción de riesgo:

• Porcentaje de repositorios críticos cubiertos por clasificación.
• Número de responsables definidos por dominio.
• Excepciones activas y porcentaje con caducidad vencida.
• Incidencias relacionadas con compartición o permisos.
• Tiempo medio para decidir si un uso de terceros o IA está permitido.
• Volumen de repositorios con acceso externo abierto sin revisión reciente.

Estas métricas permiten ajustar la práctica. Si el tiempo de decisión sigue siendo alto, el problema suele estar en criterios ambiguos o responsabilidades difusas. Si las incidencias persisten, probablemente faltan controles o formación por rol.

Errores a evitar

• Clasificar casi todo como confidencial (bloquea y no diferencia).
• Usar “restringido” como cajón de sastre.
• Delegar toda la decisión en seguridad/legal (negocio debe decidir por dominio).
• Hablar de IA solo en términos de prohibición genérica (definir condiciones de uso).
• Lanzar la política sin aplicarla a repositorios concretos (drive, CRM, BI, wikis).

Cierre: una clasificación para habilitar, no para frenar

La mejor clasificación de datos no es la más sofisticada, sino la que la organización realmente usa para decidir. Cuatro niveles suelen bastar para empezar a ordenar almacenamiento, acceso, compartición y uso en IA con un lenguaje común. A partir de ahí, el sistema puede evolucionar.

La prioridad no debería ser construir una taxonomía académica, sino establecer un marco operativo mínimo: qué dato es qué, quién decide y qué reglas se activan. Si cada equipo entiende esos tres elementos, la empresa gana velocidad con control. Y eso, hoy, es mucho más valioso que una política perfecta que nadie consulta.