Categoría: Data Governance

  • Gobernanza de datos en Ecuador: entre la norma y el valor estratégico

    Gobernanza de datos en Ecuador: entre la norma y el valor estratégico

    Ecuador atraviesa una transición concreta en la forma en que sus organizaciones tratan los datos: ya no como carga regulatoria sino como activo con valor de negocio. Entender qué implica ese cambio —y qué capacidades exige— es el punto de partida para cualquier equipo que opere en la región.

    La gobernanza de datos, en términos operativos, es el conjunto de políticas, roles, procesos y estándares que determinan quién puede hacer qué con los datos de una organización, bajo qué condiciones y con qué nivel de calidad. No es un proyecto de tecnología. Es un modelo de responsabilidad sobre el dato como recurso organizacional. La distinción importa porque en Ecuador —como en buena parte de América Latina— las iniciativas de gobernanza todavía se originan, con frecuencia, en el área de TI en lugar de nacer de una decisión de negocio respaldada por la dirección.

    Ecuador y la Ley Orgánica de Protección de Datos Personales como punto de inflexión

    La Ley Orgánica de Protección de Datos Personales (LOPDP), vigente desde 2021 y con período de adecuación que venció en mayo de 2023, le impuso a las organizaciones ecuatorianas —públicas y privadas— la obligación de documentar tratamientos, designar responsables y garantizar derechos de titulares. La autoridad de control, la Superintendencia de Protección de Datos Personales, comenzó a operar formalmente en 2023. Ese marco normativo funciona, en la práctica, como el empujón externo que obliga a las organizaciones a construir los primeros cimientos de un programa de gobernanza: inventarios de datos, clasificación por sensibilidad, asignación de ownership.

    Pero cumplir con la LOPDP no equivale a tener gobernanza de datos madura. Un inventario levantado para satisfacer un requerimiento regulatorio puede ser exactamente eso: un documento que envejece en un repositorio sin conexión con los pipelines de producción, sin un data steward que lo actualice, sin integración al catálogo de datos corporativo. La diferencia entre cumplimiento y madurez es operacional, no declarativa.

    Del inventario regulatorio al catálogo activo: qué cambia en la práctica

    Un programa de gobernanza orientado al valor estratégico requiere, al menos, cuatro capacidades que el cumplimiento regulatorio básico no garantiza. Primero, un catálogo de datos activo —no estático— donde los data stewards mantienen definiciones, clasificaciones y linaje (data lineage) en tiempo cercano al real. Segundo, métricas de calidad del dato integradas a los procesos de negocio: un campo con tasa de completitud inferior al umbral acordado dispara un flujo de corrección, no una nota de auditoría. Tercero, políticas de acceso basadas en roles y en clasificación del dato, no en acuerdos informales entre áreas. Cuarto, un modelo de stewardship —siguiendo la taxonomía del DAMA-DMBOK— que distingue entre el data owner (responsable de negocio del dato), el data steward (custodio operativo) y el data custodian (quien gestiona la infraestructura).

    En Ecuador, el sector financiero regulado por la Superintendencia de Bancos lleva ventaja relativa: las exigencias de reporte y trazabilidad de datos crediticios y de riesgo generaron, en muchas instituciones, capacidades de linaje y calidad que se pueden reutilizar como base de un programa formal. El sector público, en cambio, enfrenta el desafío adicional de la fragmentación: múltiples sistemas legados, escasa interoperabilidad y una cultura organizacional donde el dato es propiedad del área, no del estado.

    Cuándo aplica gobernanza de datos / cuándo NO es suficiente con compliance

    La gobernanza de datos como disciplina aplica cuando una organización necesita tomar decisiones repetibles y auditables sobre sus datos —independientemente de qué regulación esté vigente. No aplica como sinónimo de “tener un DPO” o “mapear tratamientos para la LOPDP”: esas son condiciones necesarias pero no suficientes. Una empresa puede estar en pleno cumplimiento regulatorio y seguir tomando decisiones de negocio con datos inconsistentes, duplicados o sin propietario claro. Gobernanza de datos resuelve ese problema estructural; el compliance regulatorio, por sí solo, no.

    Tampoco es un programa para organizaciones de cualquier tamaño indistintamente. Una pyme con veinte empleados no necesita un Council de Gobernanza de Datos con representantes de cada dominio. Sí necesita, al menos, saber qué datos tiene, quién es responsable de su calidad y cómo se mueven entre sistemas. El enfoque Non-Invasive Data Governance de Bob Seiner —que formaliza responsabilidades ya existentes sin crear estructuras paralelas— es particularmente útil en contextos con recursos limitados, algo frecuente en el ecosistema empresarial ecuatoriano fuera de banca y telecomunicaciones.

    La brecha de talento y el rol del CDO en mercados intermedios como Ecuador

    El cargo de Chief Data Officer existe todavía de forma marginal en Ecuador fuera del sector financiero y de algunas empresas de telecomunicaciones. En la mayoría de organizaciones medianas, las funciones de gobernanza recaen en el CIO o en líderes de datos sin jerarquía ejecutiva formal. Eso genera un problema de patrocinio: los programas de gobernanza que no tienen sponsor en el C-level rara vez sobreviven al primer ciclo de recorte presupuestario. Comparativamente, Brasil —donde el Banco Central empujó la madurez de datos a través del Open Finance y la ANPD consolidó su autoridad regulatoria— ya cuenta con una masa crítica de CDOs con mandato explícito sobre calidad, linaje y arquitectura de datos. Ecuador está, en ese mapa regional, en una etapa anterior pero con regulación ya activa que puede actuar como acelerador si las organizaciones deciden construir sobre ella.

    Para profundizar en el marco normativo, la Ley Orgánica de Protección de Datos Personales de Ecuador está disponible en el Registro Oficial y la Superintendencia de Protección de Datos Personales publica sus resoluciones y guías de adecuación en su sitio oficial; para el marco técnico de referencia, el DAMA-DMBOK (segunda edición) sigue siendo el estándar más citado por programas de gobernanza en la región.

  • 16.000 bases de datos en Supabase exponen datos sensibles por mala configuración

    16.000 bases de datos en Supabase exponen datos sensibles por mala configuración

    Alrededor de 16.000 bases de datos alojadas en Supabase están exponiendo información sensible de personas a la web pública, según una investigación de la firma de seguridad UpGuard divulgada el 26 de septiembre de 2026. El problema no es una vulnerabilidad del proveedor: es configuración incorrecta por parte de los propios clientes.

    UpGuard comunicó los hallazgos a TechCrunch antes de su publicación. Según se informó, la firma identificó aproximadamente 16.000 instancias de Supabase en las que algún nivel de datos quedó accesible públicamente sin autenticación. Supabase es una plataforma de desarrollo que ofrece bases de datos PostgreSQL como servicio y es ampliamente utilizada por equipos de producto y startups tecnológicas, incluyendo en América Latina. El volumen de registros expuestos no fue precisado en la información disponible, aunque la investigación describe el alcance como “reams of people’s sensitive information”, es decir, volúmenes considerables de datos personales.

    Datos confirmados al 26 de septiembre de 2026

    • Aproximadamente 16.000 bases de datos en Supabase con algún grado de exposición pública, según UpGuard.
    • La causa identificada es configuración incorrecta por parte de clientes, no una brecha en la infraestructura de Supabase.
    • El tipo de datos expuestos se describe como “información sensible de personas”, sin detalle de categorías específicas confirmadas.
    • Los hallazgos fueron reportados a TechCrunch por UpGuard antes de su publicación el 26 de septiembre de 2026.

    Qué se sabe y qué falta confirmar

    Lo confirmado hasta ahora es que el vector de exposición es la configuración de acceso público habilitada —o no restringida— en instancias de Supabase gestionadas por desarrolladores o equipos técnicos de terceros. No se ha confirmado si alguna de las bases de datos afectadas pertenece a organizaciones en América Latina, aunque la penetración de Supabase en la región como plataforma de desarrollo es significativa. Tampoco se ha informado si existió acceso no autorizado efectivo a los datos expuestos ni si alguna autoridad de protección de datos fue notificada. Lo que no está verificado: el número exacto de personas afectadas, los países involucrados, y si Supabase tomó medidas de remediación proactiva hacia sus clientes antes de la publicación.

    Desde el ángulo regulatorio, la exposición pública de datos personales por mala configuración activa obligaciones de notificación en varias jurisdicciones de la región. En Brasil, la Lei Geral de Proteção de Dados (LGPD) establece en su artículo 48 que el controlador debe comunicar incidentes a la Autoridade Nacional de Proteção de Dados (ANPD) y a los titulares afectados en un plazo razonable. En Argentina, la Ley 25.326 y las disposiciones de la AAIP también contemplan el deber de notificación ante brechas. En México, la LFPDPPP obliga al responsable del tratamiento —no al proveedor tecnológico— a gestionar el incidente. En todos estos marcos, la responsabilidad recae sobre quien decidió la configuración de acceso, no sobre el proveedor de infraestructura.

    El próximo hito crítico es la respuesta formal de Supabase a sus clientes afectados y la eventual notificación a autoridades de protección de datos en las jurisdicciones donde residan los titulares de los datos expuestos.

  • Sin gobernanza de datos, los proyectos de IA empiezan desde cero

    Sin gobernanza de datos, los proyectos de IA empiezan desde cero

    Cuando una organización lanza un proyecto de inteligencia artificial sin haber establecido gobernanza de datos, el resultado suele ser el mismo: retroceder al punto de partida para mapear, limpiar y documentar lo que debería haber estado ordenado desde antes. No es un problema de tecnología, es un problema de fundamentos.

    La gobernanza de datos es el conjunto de políticas, roles, procesos y estándares que definen quién puede hacer qué con qué datos, bajo qué condiciones y con qué nivel de calidad garantizado. En la práctica, es la diferencia entre un ecosistema de datos que una organización puede operar con confianza y un inventario opaco de activos sin dueño, sin linaje documentado y sin criterios de calidad consistentes. El marco DAMA-DMBOK, referencia global para profesionales del área, sitúa la gobernanza como la función habilitante de las otras diez disciplinas de gestión de datos: sin ella, capacidades como data quality, metadata management o data lineage quedan sin anclaje institucional.

    Por qué la IA fuerza la conversación que muchas organizaciones evitaron

    Durante años, la gobernanza de datos fue tratada como un proyecto de mediano plazo que siempre cedía ante prioridades más urgentes. La expansión de iniciativas de inteligencia artificial generativa cambió ese cálculo de forma abrupta. Entrenar un modelo, alimentar un agente o construir un sistema de recuperación aumentada (RAG) requiere saber exactamente de dónde vienen los datos, qué representan, quién los autorizó para ese uso y si su calidad es suficiente para producir outputs confiables. Sin esa información, el equipo técnico dedica semanas o meses a tareas de arqueología de datos antes de poder escribir una sola línea de código productivo. En términos de CDMC (Cloud Data Management Capabilities), del EDM Council, ese trabajo corresponde a las capabilities de Data Governance y Data Quality, que en organizaciones sin madurez formal suelen ejecutarse de manera ad hoc y sin registro.

    Los roles que faltan: data steward y data owner como piezas críticas

    Uno de los déficits más frecuentes no es de herramientas sino de responsabilidades. El modelo de Non-Invasive Data Governance que propone Bob Seiner parte de una premisa operativa: los datos ya tienen dueños de hecho —las áreas que los producen y consumen—, pero esa responsabilidad no está formalizada. Designar data stewards por dominio (finanzas, clientes, operaciones) y establecer un data owner con autoridad de decisión sobre cada activo crítico es el primer paso concreto antes de evaluar cualquier plataforma de catálogo o linaje. Sin ese mapa humano, ningún software de metadata management resuelve el problema estructural.

    Cuándo aplica la gobernanza formal y cuándo no alcanza con buenas intenciones

    La gobernanza estructurada es indispensable cuando la organización opera con datos de múltiples dominios cruzados, cuando existen obligaciones regulatorias sobre la calidad o trazabilidad de los datos, o cuando hay proyectos de IA, analítica avanzada o reporting regulatorio en marcha. No aplica —o aplica de forma mínima— en equipos muy pequeños con un solo dominio de datos bien delimitado y sin exposición regulatoria relevante. El error más común es implementar un marco complejo de gobernanza en contextos donde lo que se necesita es simplemente un acuerdo de definiciones entre tres personas. La sobreingeniería de la gobernanza es tan costosa como su ausencia.

    El ángulo regulatorio en América Latina: LGPD, Ley 25.326 y la presión desde afuera

    En la región, la gobernanza de datos dejó de ser opcional en el momento en que las regulaciones de protección de datos personales comenzaron a exigir accountability sobre el tratamiento. La Lei Geral de Proteção de Dados (LGPD) de Brasil requiere que las organizaciones puedan demostrar bases legales para cada tratamiento y acreditar medidas técnicas y organizativas adecuadas: eso es, en esencia, gobernanza aplicada a datos personales. La Ley 25.326 de Argentina —en proceso de actualización— y la Ley Federal de Protección de Datos Personales en Posesión de los Particulares (LFPDPPP) de México imponen obligaciones similares sobre inventario, propósito y seguridad de los datos. Las organizaciones que construyeron capacidades de gobernanza para cumplir con estas leyes tienen una ventaja estructural cuando llega el momento de escalar proyectos de IA: ya saben qué tienen, dónde está y quién responde por ello.

    Tres decisiones concretas para un equipo de datos sin programa formal de gobernanza

    El punto de entrada no es un comité ni una política de cien páginas. Para un CDO o Data Lead que necesita resultados en el corto plazo, el recorrido mínimo viable implica tres movimientos secuenciales:

    • Inventario de activos críticos: identificar los diez conjuntos de datos de mayor impacto para el negocio o la regulación, documentar su origen, formato, frecuencia de actualización y área responsable. Sin este paso, todo lo que sigue es especulativo.
    • Asignación de data owners y stewards: para cada activo del inventario, nombrar un responsable con autoridad para decidir sobre acceso, calidad y uso. No tiene que ser un cargo nuevo: en la mayoría de los casos, esa persona ya existe y solo necesita que la responsabilidad sea explícita.
    • Definición de criterios de calidad mínimos: establecer, por dominio, qué significa que un dato es “suficientemente bueno” para ser usado en un proceso de negocio o en un modelo. Completitud, unicidad, consistencia temporal: tres dimensiones básicas que el framework ISO/IEC 25012 ya define y que pueden operacionalizarse sin infraestructura compleja.

    Estos tres pasos no reemplazan un programa maduro de gobernanza, pero eliminan el síntoma más costoso: el equipo que no sabe qué tiene ni a quién preguntar cuando un proyecto se traba en el primer sprint.

    La gobernanza de datos no es el proyecto que viene después de la IA: es la condición sin la cual la IA es, en el mejor caso, un experimento que no escala. Para lectura de referencia, el DAMA-DMBOK (segunda edición) y el marco CDMC del EDM Council son los puntos de partida técnicos más sólidos disponibles hoy para equipos de la región.

  • Puerto de Los Ángeles bloqueó 120 millones de ciberataques en agosto

    Puerto de Los Ángeles bloqueó 120 millones de ciberataques en agosto

    El Puerto de Los Ángeles —el hub de contenedores más activo de Estados Unidos— repelió más de 120 millones de ciberataques durante agosto de 2026, según informó Bloomberg News el 17 de septiembre citando declaraciones del director ejecutivo del puerto, Gene Seroka. La cifra convierte a esta infraestructura crítica en uno de los blancos más atacados del sector logístico global.

    Seroka confirmó el volumen de ataques en el marco de una discusión más amplia sobre amenazas operativas al comercio internacional, en un contexto de tensión arancelaria que eleva el valor estratégico —y la exposición política— de los principales puertos estadounidenses. El Puerto de Los Ángeles procesa una proporción significativa del comercio contenedorizado entre Asia y América del Norte, lo que lo convierte en objetivo prioritario tanto para actores estatales como para grupos de ransomware con motivaciones económicas.

    120 millones de intentos: volumen, no vulneraciones confirmadas

    • Período: agosto de 2026 (31 días)
    • Volumen reportado: más de 120 millones de ciberataques bloqueados
    • Fuente primaria: Gene Seroka, director ejecutivo del Puerto de Los Ángeles, según Bloomberg News
    • Infraestructura afectada: hub de contenedores de mayor tráfico en EE.UU.
    • Exfiltración de datos confirmada: ninguna según se informó hasta el momento de la publicación

    Qué está confirmado y qué falta verificar

    Lo confirmado, según Bloomberg: el volumen de intentos bloqueados y la condición de amenaza operativa continua. Lo que no se ha precisado públicamente incluye la naturaleza técnica de los ataques (denegación de servicio, intentos de intrusión, phishing dirigido), la atribución a actores específicos, y si algún sistema de gestión de carga o datos logísticos fue comprometido de forma parcial. La ausencia de notificación de brecha no equivale a seguridad total: en infraestructuras críticas, los ataques de reconocimiento no siempre dejan rastro inmediato.

    El contexto arancelario mencionado por Seroka es relevante: los puertos que operan como nodos de re-ruteo comercial ante restricciones tarifarias concentran flujos de datos sensibles —manifiestos de carga, información de importadores, datos de cadena de suministro— que tienen valor de inteligencia económica. En América Latina, puertos como el de Santos (Brasil), Manzanillo (México) y el Callao (Perú) operan con exposición similar pero con marcos de respuesta a incidentes notoriamente menos maduros. Brasil cuenta con la LGPD y con lineamientos del Banco Central para infraestructuras financieras críticas, pero la regulación sectorial portuaria aún no exige notificación de incidentes cibernéticos en plazos definidos. México, bajo la LFPDPPP, tampoco tiene un régimen específico de reporte obligatorio para infraestructuras de transporte.

    El próximo hito a seguir: si el Puerto de Los Ángeles activa algún protocolo formal de divulgación ante la Agencia de Seguridad de Infraestructura y Ciberseguridad (CISA) de EE.UU., ese reporte podría revelar datos técnicos que hoy no están disponibles.

  • Gobernanza de datos y confianza digital como ejes de competitividad empresarial en Mozambique

    Gobernanza de datos y confianza digital como ejes de competitividad empresarial en Mozambique

    Mozambique se suma a la lista de economías africanas que identifican la gobernanza de datos y la confianza digital como palancas directas de competitividad empresarial, no como cumplimiento periférico. El debate ya no es si gestionar los datos con rigor importa, sino qué capacidades concretas necesitan las organizaciones para que ese rigor se traduzca en ventaja de mercado.

    Según se informó, el sector empresarial y el ecosistema tecnológico de Mozambique han comenzado a articular gobernanza de datos y confianza digital como factores diferenciadores en la atracción de inversión y en la sostenibilidad operativa. El movimiento refleja una tendencia que en América Latina lleva varios años de recorrido: la gobernanza de datos dejó de ser un proyecto de TI para convertirse en una conversación de directorio.

    Qué significa “confianza digital” en términos operativos para una organización

    La confianza digital no es una declaración de intenciones: es el resultado medible de procesos de gobernanza que garantizan que los datos son precisos, están protegidos y son utilizados de forma transparente. En el marco CDMC (Cloud Data Management Capabilities) del EDM Council, la confianza digital se construye sobre capabilities verificables —clasificación, linaje, calidad, control de acceso— y no sobre promesas de política. Una organización que no puede demostrar quién modificó un dato, cuándo y con qué propósito, no tiene confianza digital: tiene aspiración.

    El DAMA-DMBOK v2 ubica la calidad del dato y el linaje (data lineage) como habilitadores transversales de todas las demás áreas de conocimiento. Sin ellos, iniciativas de analítica avanzada, apertura de datos a socios comerciales o integración con plataformas externas quedan expuestas a errores de decisión que erosionan la reputación institucional —y con ella, la competitividad.

    Por qué la competitividad empresarial depende cada vez más de los datos bien gobernados

    El argumento competitivo de la gobernanza de datos opera en al menos tres dimensiones. Primero, la eficiencia operativa: organizaciones con catálogos de datos activos y data stewards asignados reducen el tiempo de búsqueda y validación de información para la toma de decisiones. Segundo, la confiabilidad ante socios e inversores: en contextos de due diligence, la capacidad de demostrar trazabilidad y control sobre los activos de datos es un diferenciador concreto. Tercero, el acceso a mercados regulados: cada vez más licitaciones públicas y contratos internacionales exigen evidencia de prácticas de gobernanza como condición de elegibilidad.

    John Ladley, en su trabajo sobre estrategia de información, señala que las organizaciones que tratan los datos como activos estratégicos —con propietarios definidos, políticas claras y métricas de calidad— obtienen retornos medibles en reducción de riesgo operativo y en velocidad de lanzamiento de productos basados en datos. El caso de Mozambique ilustra que este razonamiento ya cruzó el Atlántico y el Índico: no es patrimonio de economías del G7.

    Cuándo aplica este enfoque y cuándo no basta con declararlo

    La gobernanza de datos como driver de competitividad aplica cuando existe una estructura mínima de ownership: al menos un data steward por dominio crítico de negocio, un registro activo de activos de datos (aunque sea en una hoja de cálculo versionada), y un proceso documentado de resolución de problemas de calidad. Sin esa base, hablar de “confianza digital” es marketing interno. No aplica como ventaja competitiva real en organizaciones donde los datos viven en silos sin propietario asignado, donde no existe un proceso de clasificación por criticidad, o donde el equipo de gobernanza reporta exclusivamente a TI sin interlocución con el negocio.

    El recorrido de América Latina: lecciones que Mozambique puede tomar prestadas

    En América Latina, la gobernanza de datos como argumento competitivo encontró un acelerador inesperado en los marcos regulatorios. Brasil, con la Lei Geral de Proteção de Dados (LGPD, Lei 13.709/2018) y la Autoridade Nacional de Proteção de Dados (ANPD) activa desde 2021, empujó a las organizaciones a inventariar sus datos personales —y muchas descubrieron en ese proceso que no sabían qué datos tenían, dónde estaban ni quién era responsable. Argentina, con la Ley 25.326 y su autoridad de control (AAIP), atravesó una dinámica similar. En Colombia, la Ley 1581 de 2012 generó el mismo efecto: el cumplimiento de privacidad fue la puerta de entrada a programas de gobernanza más amplios. Mozambique parte de un contexto regulatorio diferente, pero el vector es el mismo: la presión externa —regulatoria o de mercado— acelera la madurez interna.

    Los CDOs de la región que lograron posicionar la gobernanza de datos como argumento de negocio no lo hicieron con frameworks abstractos: lo hicieron mostrando el costo de no gobernar. Incidentes de calidad que derivaron en decisiones erróneas con impacto financiero medible, auditorías fallidas por falta de linaje documentado, contratos perdidos por no poder demostrar controles de acceso. Esos casos concretos —no los decálogos de mejores prácticas— son los que mueven presupuesto.

    Tres movimientos concretos para un CDO que quiere traducir este debate en acción

    • Mapear los dominios de datos críticos del negocio e identificar si existe un data steward designado para cada uno. Si no existe, ese es el primer gap a cerrar antes de cualquier conversación sobre confianza digital.
    • Construir un caso de negocio basado en el costo de los problemas de calidad actuales: decisiones revertidas, reportes rehechos, integraciones fallidas. Ese número, expresado en horas/hombre o en impacto en revenue, es el argumento que llega a CFO y CEO.
    • Vincular el programa de gobernanza al cumplimiento regulatorio vigente —LGPD, Ley 25.326, Ley 1581 o la norma local aplicable— para obtener respaldo institucional y presupuesto con urgencia justificada.

    Para profundizar en los frameworks de referencia, el DAMA-DMBOK v2 y el CDMC del EDM Council son los puntos de partida obligados; ambos están disponibles en sus respectivos sitios oficiales con documentación técnica descargable.

  • Agentes de IA: recuperar hechos, no definirlos

    Agentes de IA: recuperar hechos, no definirlos

    Los agentes de inteligencia artificial no deben ser la fuente de verdad de una organización: deben consultar esa fuente, no reemplazarla. La distinción parece obvia hasta que un agente empieza a responder preguntas de negocio con datos que nadie auditó, en pipelines que nadie gobierna.

    Cuando una organización despliega agentes de IA para automatizar decisiones —desde aprobación de créditos hasta reportes regulatorios—, uno de los riesgos más subestimados no es técnico sino semántico: el agente puede “definir” un hecho porque ningún sistema autoritativo le indicó cuál es la versión correcta. Si no existe un catálogo de datos activo, un ownership claro por dominio y reglas de calidad documentadas, el agente opera en el vacío y llena ese vacío con inferencias. Eso no es inteligencia artificial; es ambigüedad automatizada a escala.

    Qué significa que un agente “defina” un hecho

    En arquitecturas de recuperación aumentada (RAG) o en agentes con acceso a múltiples fuentes, el sistema elige qué dato usar cuando encuentra versiones contradictorias. Si no hay una capa de gobernanza que declare cuál sistema es el registro maestro —el sistema of record— para cada concepto crítico de negocio (cliente, producto, saldo, riesgo), el agente toma esa decisión de facto. Lo hace de forma opaca, no documentada y, en muchos casos, no reproducible. El problema no es el modelo de lenguaje en sí: es la ausencia del marco de datos que debería preceder a cualquier despliegue agentico.

    Cuándo aplica / cuándo NO

    Este riesgo aplica en cualquier flujo donde el agente accede a más de una fuente de datos para construir una respuesta o tomar una acción: consultas sobre clientes en CRM + ERP, generación de reportes desde múltiples data marts, o automatización de procesos con datos de terceros. No aplica —o aplica con menor urgencia— cuando el agente opera sobre una única fuente de datos bien delimitada, con esquema fijo y ownership documentado. En ese escenario reducido, el agente efectivamente “recupera” sin riesgo de “definir”. El problema escala con la complejidad del ecosistema de datos.

    El DAMA-DMBOK y la capa que falta antes del agente

    El marco DAMA-DMBOK identifica la gestión de datos maestros (MDM, Master Data Management) y la gestión de datos de referencia como disciplinas previas a cualquier consumo analítico o automatizado. Un agente de IA es, a efectos prácticos, un consumidor de datos de alta velocidad y baja supervisión humana. Si los datos maestros de cliente no tienen un data steward asignado, si el glosario de negocio no está publicado y si el data lineage no traza de dónde viene cada atributo, el agente heredará todos esos problemas —y los amplificará, porque operará sin fricción humana correctiva. La secuencia correcta es: definir el dato canónico → documentar su linaje → habilitar el acceso al agente, no al revés.

    Tres controles concretos antes de escalar agentes en producción

    • Designar un data steward por dominio crítico (cliente, producto, riesgo, transacción) con autoridad explícita para declarar el sistema of record. Sin ese ownership, el agente no tiene a quién consultar cuando hay conflicto entre fuentes.
    • Publicar un glosario de negocio vinculado al catálogo de datos. Cada concepto que el agente puede consultar debe tener una definición aprobada, una fuente autoritativa y una fecha de revisión. Herramientas como Collibra, Alation o Apache Atlas permiten implementarlo; lo que no puede delegarse en la herramienta es la decisión sobre qué definición es la correcta.
    • Implementar trazabilidad (data lineage) a nivel de atributo en los datasets que alimentan al agente. Si el agente devuelve un resultado que luego se cuestiona, el equipo de gobernanza debe poder responder en minutos de dónde vino ese dato, quién lo transformó y cuándo.

    Bancos y aseguradoras en LATAM ya enfrentan esta tensión

    En Argentina, las entidades financieras bajo supervisión del BCRA deben garantizar la integridad de la información reportada —la Comunicación A 7724 y sus actualizaciones establecen controles sobre la calidad y consistencia de los datos prudenciales—. Si un agente de IA interviene en la generación de esos reportes sin una capa de MDM robusta, la entidad expone no solo la calidad del reporte sino su trazabilidad ante el regulador. En Brasil, la resolución BCB 85/2021 que regula el Open Finance impone estándares similares sobre consistencia de datos compartidos entre instituciones. En ambos casos, el regulador espera datos trazables y auditables; un agente sin gobernanza de datos subyacente no puede garantizar ninguna de las dos condiciones.

    En México, el marco de la CNBV sobre gestión de riesgos tecnológicos también demanda controles sobre la calidad e integridad de los datos utilizados en sistemas de decisión automatizada. Los equipos de datos que estén evaluando agentes de IA para procesos regulados deben mapear primero qué datos consume el agente, qué define como “fuente verdadera” cuando hay conflicto y quién es responsable si esa definición es incorrecta. Si ninguna de esas preguntas tiene respuesta documentada, el agente no está listo para producción regulada.

    Para leer los principios de gestión de datos maestros y referencia en profundidad, el DAMA-DMBOK 2.0 (capítulos 9 y 10) y el framework CDMC del EDM Council son los puntos de partida más rigurosos disponibles para equipos que necesitan construir esa capa antes de escalar agentes.

  • Evaluación de IA en América Latina: gobernanza de datos, el eslabón más débil

    Evaluación de IA en América Latina: gobernanza de datos, el eslabón más débil

    Las evaluaciones de sistemas de inteligencia artificial en la región revelan un patrón consistente: la gobernanza de datos es la capacidad con mayor brecha de madurez, y su debilidad socava cualquier iniciativa de IA antes de que llegue a producción. Sin datos bien catalogados, con linaje trazable y ownership definido, los modelos operan sobre cimientos inestables.

    Cuando una organización decide evaluar su preparación para implementar inteligencia artificial, el diagnóstico casi siempre apunta al mismo cuello de botella: no es la ausencia de talento técnico ni la falta de infraestructura computacional. Es la incapacidad de responder preguntas básicas sobre sus propios datos — quién los posee, qué significan, de dónde vienen y si son confiables. Ese conjunto de capacidades es lo que el marco DAMA-DMBOK agrupa bajo gobernanza de datos, y es precisamente donde los diagnósticos regionales muestran las brechas más pronunciadas.

    Por qué la IA expone lo que la gobernanza de datos no resolvió

    Un sistema de machine learning o un modelo de lenguaje grande (LLM) desplegado en producción necesita datos de entrenamiento documentados, pipelines auditables y metadata que permita rastrear el origen de cada conjunto de datos. Sin eso, el modelo puede producir resultados correctos en un entorno controlado y fallar de forma impredecible en producción. La IA no crea el problema de gobernanza — lo vuelve visible y costoso. Lo que antes era una deuda técnica tolerada se convierte, en un contexto de IA, en riesgo operativo y regulatorio concreto.

    El EDM Council, organismo que administra el marco CDMC (Cloud Data Management Capabilities), identifica 14 capacidades de gestión de datos organizadas en niveles de madurez del 1 al 5. Según evaluaciones publicadas por el mismo consejo, la mayoría de las organizaciones globales opera entre nivel 1 y 2 en las capacidades de data quality, data lineage y data ownership — las tres directamente críticas para proyectos de IA. La región latinoamericana no es la excepción, y en sectores como gobierno, salud y retail, el punto de partida suele ser más bajo que el promedio global.

    Qué significa “brecha de gobernanza” en términos operativos

    Una brecha de gobernanza en contexto de IA se manifiesta en al menos cuatro formas concretas: primero, datos sin propietario definido (data steward ausente o rol no formalizado); segundo, ausencia de catálogo de datos que permita descubrir qué conjuntos existen y cuál es su calidad; tercero, linaje de datos (data lineage) no documentado, lo que impide saber cómo se transformaron los datos de origen a los datos de entrenamiento; y cuarto, ausencia de políticas de clasificación que distingan datos sensibles, regulados o de uso restringido. Cualquiera de estas cuatro condiciones es suficiente para frenar o invalidar una iniciativa de IA.

    Cuándo aplica esta evaluación y cuándo no

    Este análisis aplica a organizaciones que están en proceso de adoptar IA con datos propios — sea mediante modelos propietarios, fine-tuning de modelos base, o integración de APIs de modelos externos con datos internos. No aplica en la misma medida a organizaciones que usan IA exclusivamente a través de interfaces de usuario externas sin conectar datos internos, aunque incluso en ese caso la gobernanza de los datos exportados hacia esos sistemas sigue siendo un riesgo que debe gestionarse.

    El marco regulatorio en LATAM presiona desde afuera

    La presión para mejorar la gobernanza de datos no viene solo del imperativo técnico de la IA. En Brasil, la LGPD (Lei Geral de Proteção de Dados, Lei 13.709/2018) exige que las organizaciones puedan responder solicitudes de titulares sobre el tratamiento de sus datos, lo que requiere exactamente el tipo de catálogo y linaje que las brechas de gobernanza impiden. En México, la LFPDPPP establece obligaciones equivalentes gestionadas por el INAI. En Argentina, la Ley 25.326 y su autoridad de control, la AAIP, han intensificado la supervisión sobre tratamientos automatizados. Una organización que no puede mapear sus flujos de datos para responder a un DSAR (Data Subject Access Request) tampoco puede documentar el entrenamiento de un modelo de IA ante un regulador. La brecha de gobernanza es simultáneamente un problema técnico, un problema de IA y un problema de cumplimiento normativo.

    Costa Rica, que en los últimos años ha posicionado su sector tecnológico como uno de los más activos de Centroamérica, enfrenta esta misma tensión: la adopción de IA en sectores como servicios financieros y gobierno digital avanza más rápido que la madurez de gobernanza de datos en las organizaciones que la implementan. La Agencia de Protección de Datos de los Habitantes (PRODHAB) supervisa el cumplimiento de la Ley 8968, que incluye obligaciones sobre tratamientos automatizados relevantes para sistemas de IA.

    Tres capacidades para priorizar antes de cualquier proyecto de IA

    Con base en los marcos de referencia disponibles — DAMA-DMBOK, CDMC y las recomendaciones del MIT CISR sobre gobierno de datos para IA — hay tres capacidades que deben establecerse antes de escalar cualquier iniciativa de IA con datos propios. Primero, asignar data stewards para los dominios de datos que alimentarán los modelos, con responsabilidades documentadas y formalizadas. Segundo, implementar un catálogo de datos mínimo viable que registre al menos origen, clasificación de sensibilidad y calidad básica de los conjuntos de datos candidatos. Tercero, documentar el data lineage de extremo a extremo para los pipelines de entrenamiento, de modo que cualquier auditoría interna o regulatoria pueda reconstruir cómo se produjo el modelo. Estas tres capacidades no requieren herramientas sofisticadas para comenzar — pueden iniciarse con procesos documentados antes de que exista una plataforma tecnológica dedicada.

    Para profundizar en los marcos de referencia, el DAMA-DMBOK 2.0 y la documentación pública del EDM Council sobre CDMC están disponibles en sus respectivos sitios oficiales; la Ley 8968 de Costa Rica y las resoluciones de PRODHAB se encuentran en el Sistema Costarricense de Información Jurídica (SCIJ).

  • Río Negro legisla gobernanza de datos públicos: qué plantea el proyecto

    Río Negro legisla gobernanza de datos públicos: qué plantea el proyecto

    La Legislatura de Río Negro avanza en un proyecto de ley de gobernanza de datos públicos, según se informó a mediados de septiembre de 2025. Si prospera, la provincia patagónica se convertiría en una de las primeras jurisdicciones subnacionales de Argentina en contar con un marco normativo específico para la gestión del dato público —un terreno donde la regulación nacional lleva años de retraso.

    La iniciativa, cuyo texto completo no fue publicado oficialmente al cierre de esta edición, apunta a establecer criterios para la apertura, clasificación y uso de datos que produce y custodia el Estado provincial. El movimiento legislativo llega en un momento en que varias provincias argentinas están revisando sus marcos de modernización del Estado, pero sin traducirlos aún en reglas concretas de gobernanza del dato.

    Argentina: vacío federal y avances provinciales en 2025

    A nivel nacional, Argentina carece de una ley de gobernanza de datos públicos como instrumento específico. La Ley 27.275 de Acceso a la Información Pública, sancionada en 2016 y reglamentada por el Decreto 206/2017, establece el derecho de acceso y obliga a publicar información en formatos abiertos, pero no define un marco de gestión, calidad ni ciclo de vida del dato dentro del Estado. El Plan Nacional de Gobierno Abierto y los decretos de datos abiertos del Ejecutivo nacional (entre ellos el Decreto 117/2016) avanzaron en apertura, pero sin arquitectura de gobernanza: no hay roles de data steward en el sector público, ni un catálogo central con linaje definido, ni políticas de calidad del dato vinculantes para organismos nacionales.

    En ese vacío, las provincias empiezan a moverse. Río Negro no sería la primera en intentarlo: la Ciudad Autónoma de Buenos Aires tiene regulaciones de datos abiertos (Ley 4.013 y normas complementarias) y Santa Fe avanzó con el programa Datos Abiertos SF, aunque ninguna de las dos alcanzó aún una ley integral de gobernanza con responsabilidades, estándares y mecanismos de enforcement explícitos. Si el proyecto rionegrino llega a sancionarse con esas características, marcaría un precedente legislativo relevante para el federalismo argentino en materia de dato público.

    Brasil, Chile y Colombia: tres modelos de referencia para el sector público

    En el resto de la región, el avance es dispar pero hay referencias concretas que un equipo legislativo debería tener sobre la mesa. Brasil sancionó en 2021 la Lei nº 14.129 (Lei do Governo Digital), que define principios de gobernanza de datos para el sector público federal e impulsa la interoperabilidad entre organismos, complementando la LGPD (Lei nº 13.709/2018) en el tratamiento de datos personales por el Estado. Chile, por su parte, incorporó en su nueva Ley 21.719 de Protección de Datos Personales —promulgada en 2024— disposiciones específicas sobre el tratamiento de datos por órganos públicos, con estándares de calidad y finalidad definidos. Colombia opera con la Política de Gobierno Digital (antes GEL) y la Resolución MinTIC que regula los datos abiertos, aunque aún no tiene una ley de gobernanza de dato público como tal.

    El marco de referencia conceptual más robusto para iniciativas de este tipo sigue siendo el DAMA-DMBOK (Data Management Body of Knowledge), que en su segunda edición distingue entre apertura del dato (open data) y gobernanza del dato (data governance): la primera es una política de acceso; la segunda es un sistema de gestión con ownership, calidad, ciclo de vida y controles. Un proyecto legislativo que solo regule apertura sin abordar las otras dimensiones reproduce el error que ya cometieron varios gobiernos en la región.

    Qué debería contener una ley provincial de gobernanza de datos para ser efectiva

    Basándonos en los marcos internacionales y en la experiencia regulatoria regional, un instrumento de gobernanza de datos públicos que aspire a ser operativo debería contemplar al menos los siguientes elementos:

    • Definición de roles formales: quién es el data owner y quién el data steward en cada organismo, con responsabilidades explícitas y no meramente declarativas.
    • Catálogo de datos públicos con metadatos estandarizados y linaje documentado, de modo que sea posible rastrear el origen, transformación y uso de cada conjunto de datos.
    • Estándares de calidad del dato: completitud, exactitud, actualidad y consistencia como requisitos mínimos medibles, no principios generales.
    • Clasificación de datos según sensibilidad, con criterios que distingan datos abiertos, datos reservados y datos de acceso restringido por razones de privacidad o seguridad.
    • Mecanismo de supervisión y enforcement: un órgano o autoridad con capacidad de auditar el cumplimiento, no solo de emitir recomendaciones.

    Sin estos componentes, la ley corre el riesgo de convertirse en una declaración de principios sin efecto práctico en la operación del Estado provincial.

    Qué monitorear: texto definitivo, comisiones y articulación con la Ley 25.326

    El siguiente paso crítico es la publicación del texto del proyecto y su tratamiento en comisiones. Hay dos puntos de tensión técnica que merecen seguimiento. El primero es la articulación con la Ley 25.326 de Protección de Datos Personales: cualquier régimen de gobernanza de datos públicos en Argentina debe ser coherente con las obligaciones de esa ley —y, eventualmente, con las reformas que el Ejecutivo nacional viene evaluando desde 2023—, especialmente en lo que refiere al tratamiento de datos personales que obran en registros estatales. El segundo es la capacidad institucional de implementación: la provincia deberá definir si crea una unidad específica de gobernanza de datos, si recae en la Secretaría de Modernización o si designa un responsable transversal con autoridad real sobre los organismos.

    Nuestro análisis

    El valor de la iniciativa rionegrina no está en ser la primera —porque la Ciudad de Buenos Aires lleva ventaja en apertura de datos—, sino en el nivel de ambición que tenga el texto. En Argentina, el federalismo produce un mosaico regulatorio donde una provincia puede legislar mejor que la nación en materias técnicas como esta. Si Río Negro aprueba una ley con roles definidos, catálogo obligatorio y enforcement real, generará una presión normativa ascendente que otras provincias y eventualmente el Congreso nacional difícilmente podrán ignorar. El riesgo opuesto, igualmente real, es que el proyecto se diluya en una ley de apertura de datos rebautizada como “gobernanza”, que es exactamente lo que la región ya tiene en abundancia y no le alcanza.

    La diferencia entre una ley de datos abiertos y una ley de gobernanza de datos es la diferencia entre publicar información y gestionarla: Río Negro tiene la oportunidad de legislar la segunda, pero el texto dirá si eso es lo que realmente ocurrió.

  • Por qué los líderes de datos no confían aún en que la IA actúe sola

    Por qué los líderes de datos no confían aún en que la IA actúe sola

    En un evento reciente organizado por Ataccama con líderes senior de datos de grandes empresas, ninguno de los participantes se mostró dispuesto a permitir que los agentes de inteligencia artificial operen con autonomía plena. La presión para escalar IA a velocidad de máquina existe, pero el freno está puesto deliberadamente —y los motivos son de gobernanza, no de tecnología.

    La distinción importa. Cuando los responsables de datos frenan la autonomía de los agentes de IA, no es porque los sistemas no funcionen: es porque las estructuras de ownership, trazabilidad y control de calidad del dato no están lo suficientemente maduras como para delegar decisiones consecuentes a un sistema automatizado. Dicho de otro modo, el problema no está en el modelo; está en los cimientos de datos sobre los que ese modelo opera.

    Autonomía de agentes de IA: qué implica ejecutar “a velocidad de máquina”

    Un agente de IA autónomo no solo recomienda una acción: la ejecuta. Puede modificar registros, desencadenar flujos de trabajo, interactuar con sistemas externos o tomar decisiones de negocio sin intervención humana en cada paso. En entornos donde el dato es insumo crítico —bancos, aseguradoras, sistemas de salud, retailers con operaciones de cadena de suministro complejas— esa capacidad de actuación sin supervisión directa representa un riesgo operativo que los líderes de datos evalúan con extrema cautela, según se desprende del encuentro organizado por Ataccama. El marco DAMA-DMBOK ubica esta tensión exactamente en la intersección entre Data Quality Management y Data Architecture: si el dato de entrada no tiene calidad certificada y ownership claro, ningún nivel de sofisticación del modelo mitiga el riesgo de decisión errada.

    Cinco señales de alerta que frenan la ejecución autónoma

    Del evento participado por líderes senior de datos se pueden extraer, según se informó, al menos cinco vectores de preocupación que explican la resistencia a la autonomía total de los agentes:

    • Ausencia de data lineage confiable: si no es posible trazar con certeza el origen y las transformaciones de un dato, no es posible auditar la decisión del agente que lo consumió.
    • Ownership difuso: sin un data steward claramente asignado a cada dominio de dato, no hay un humano responsable de validar que el input del agente es correcto antes de la ejecución.
    • Catálogos de datos incompletos: los agentes necesitan contexto semántico del dato para operar bien; un catálogo desactualizado es un vector de error silencioso.
    • Falta de métricas de calidad en tiempo real: la autonomía requiere que el agente sepa, en el momento de actuar, si el dato que consume cumple los umbrales de calidad definidos.
    • Ausencia de circuit breakers de gobernanza: no existe aún, en la mayoría de las organizaciones, un mecanismo formal que interrumpa la ejecución del agente cuando detecta anomalías en el dato de entrada.

    Cuándo aplica la supervisión humana y cuándo no es suficiente con políticas

    La supervisión humana en el loop de un agente de IA no es lo mismo que tener una política que diga “los humanos aprueban las decisiones”. Aplicar supervisión real implica que el agente genera una recomendación, expone su razonamiento y el data steward o el responsable de dominio puede rechazarla con evidencia antes de que se ejecute. Este modelo —conocido como human-in-the-loop (HITL)— es el que los líderes consultados por Ataccama prefieren para los casos de uso de alto impacto. El modelo human-on-the-loop (HOTL), donde el agente actúa y el humano puede intervenir a posteriori, es aceptable solo cuando el costo de reversión es bajo y el dato de entrada tiene calidad certificada. La autonomía total —sin supervisión activa— no encontró defensores en el evento.

    El contexto regulatorio en América Latina presiona en la misma dirección

    La cautela de los líderes de datos coincide con el marco regulatorio que se está consolidando en la región. En Brasil, la Lei Geral de Proteção de Dados (LGPD) establece el derecho a revisión humana de decisiones automatizadas con efectos significativos sobre personas (artículo 20), lo que obliga a las empresas a mantener capacidad de supervisión activa sobre cualquier agente que opere con datos personales. En Argentina, la Agencia de Acceso a la Información Pública (AAIP) viene avanzando en lineamientos sobre IA responsable que apuntan en la misma dirección. En México, el Instituto Nacional de Transparencia, Acceso a la Información y Protección de Datos Personales (INAI) ha señalado la necesidad de explicabilidad en decisiones automatizadas. Ninguno de estos marcos permite, en la práctica, que un agente de IA tome decisiones sobre datos personales sin trazabilidad auditada y posibilidad de revisión: exactamente lo que los líderes de datos identifican como condición faltante en sus organizaciones.

    Qué necesita estar resuelto antes de escalar agentes autónomos

    Para un Chief Data Officer que evalúa cuándo y cómo escalar agentes de IA con mayor autonomía, el camino crítico pasa por tres decisiones de gobernanza que deben estar tomadas antes de mover el dial hacia la autonomía. Primero, certificar la calidad del dato de entrada para cada dominio donde el agente va a operar —no de forma general, sino dominio por dominio, con umbrales definidos y monitoreados en tiempo real. Segundo, asignar formalmente un data steward con ownership sobre los datos que consume el agente, con capacidad efectiva de vetar una ejecución. Tercero, construir data lineage auditado end-to-end para los flujos que alimentan al agente, de modo que cualquier decisión sea reconstruible y explicable ante una auditoría interna o regulatoria. El EDM Council, a través del marco CDMC (Cloud Data Management Capabilities), ubica estas tres capacidades en los niveles 6, 7 y 8 del modelo de madurez —niveles que la mayoría de las organizaciones latinoamericanas aún no ha certificado formalmente, aunque muchas operen con prácticas equivalentes en sectores regulados como banca y seguros.

    La autonomía de los agentes de IA no es una decisión de arquitectura tecnológica: es una declaración sobre el nivel de madurez del gobierno de datos de una organización. Los líderes que hoy frenan la autonomía total no están siendo conservadores —están siendo precisos.

  • De detectar a controlar: ciberseguridad adopta gobernanza de datos como eje

    De detectar a controlar: ciberseguridad adopta gobernanza de datos como eje

    La ciberseguridad corporativa está cambiando de paradigma: ya no alcanza con detectar amenazas después del hecho; el nuevo estándar exige control preventivo y gobernanza de datos integrada desde el diseño. El giro no es cosmético — implica redefinir quién es responsable del dato, no solo de la red.

    Durante años, el modelo dominante en seguridad de la información se construyó sobre la detección: sistemas SIEM, análisis de comportamiento, respuesta a incidentes. El supuesto implícito era que los ataques ocurrirían y que la velocidad de respuesta definiría el daño. Ese supuesto está siendo cuestionado por una corriente creciente dentro de la industria, según se informó desde el mercado mexicano, que apunta a los controles preventivos y a la gobernanza estructurada de datos como la capa de defensa más eficaz a largo plazo.

    Por qué la detección sola ya no alcanza en entornos con datos distribuidos

    La proliferación de entornos multicloud, el trabajo remoto sostenido y la expansión de pipelines de inteligencia artificial generaron un volumen de datos en movimiento que supera la capacidad de monitoreo reactivo. Cuando una organización no sabe con precisión qué datos tiene, dónde residen y quién puede acceder a ellos, cualquier sistema de detección opera con información incompleta. El DAMA-DMBOK, referencia estándar de la industria de gobernanza de datos, establece que el área de Seguridad de Datos es una de las once áreas de conocimiento del marco justamente porque el control de acceso, la clasificación y el ciclo de vida del dato son condiciones previas a cualquier estrategia de defensa efectiva.

    El concepto que gana terreno es el de “data control”: saber no solo que un dato existe, sino quién es su data owner, qué clasificación de sensibilidad tiene, qué transformaciones sufrió (data lineage) y bajo qué política de retención opera. Sin esas definiciones en un catálogo de datos activo, el equipo de seguridad trabaja sobre un mapa incompleto.

    El rol del data steward en la nueva frontera de seguridad

    El desplazamiento hacia el control preventivo eleva el perfil del data steward — el rol responsable de aplicar políticas de gobernanza sobre dominios de datos específicos — como interlocutor directo del Chief Information Security Officer (CISO). En el modelo tradicional, seguridad y gobernanza operaban en silos: uno gestionaba firewalls y endpoints; el otro, metadatos y calidad. La convergencia implica que las políticas de acceso a datos sensibles deben surgir de decisiones de gobernanza, no solo de configuraciones técnicas de red.

    Bob Seiner, referente del Non-Invasive Data Governance, sostiene que la asignación de responsabilidad sobre los datos debe reflejar quién los usa en el negocio, no solo quién los almacena en IT. Esa lógica es directamente aplicable al control preventivo: si el data steward del dominio “clientes” define que ciertos campos de PII solo pueden ser consultados por roles específicos, esa política puede traducirse en controles de acceso automatizados que reducen la superficie de ataque antes de que ocurra cualquier incidente.

    Cuándo aplica este enfoque y cuándo no reemplaza a la detección

    El modelo de gobernanza como capa de seguridad es especialmente relevante en organizaciones con grandes volúmenes de datos regulados: instituciones financieras, operadoras de salud, empresas con datos de consumidores a escala. En esos contextos, los beneficios son dobles: reducción de riesgo y cumplimiento normativo simultáneo. Sin embargo, este enfoque no elimina la necesidad de detección — la complementa. Las amenazas internas, los ataques a la cadena de suministro de software y las vulnerabilidades de día cero requieren capacidades de respuesta que la gobernanza sola no puede cubrir. La tesis correcta no es “control en lugar de detección”, sino “control como condición habilitante de una detección más precisa”.

    México, Argentina y Brasil: marcos regulatorios que aceleran la convergencia

    En América Latina, la presión regulatoria está funcionando como catalizador de esta convergencia. En México, la Ley Federal de Protección de Datos Personales en Posesión de los Particulares (LFPDPPP) y su reglamento exigen medidas de seguridad administrativas, físicas y técnicas que incluyen implícitamente controles de gobernanza sobre datos personales. En Brasil, la Lei Geral de Proteção de Dados (LGPD) va más lejos al requerir que el controlador demuestre la base legal del tratamiento de cada categoría de dato — lo que supone tener un catálogo de datos personales activo y auditado. En Argentina, la Ley 25.326 y las disposiciones de la AAIP (Agencia de Acceso a la Información Pública) establecen obligaciones de seguridad que, interpretadas en contextos de auditoría, demandan exactamente el tipo de trazabilidad que provee un programa de gobernanza maduro.

    Las organizaciones que ya operan con frameworks como el CDMC (Cloud Data Management Capabilities) del EDM Council o con controles equivalentes al dominio de Seguridad del DAMA-DMBOK tienen una ventaja concreta: pueden responder a requerimientos regulatorios de múltiples jurisdicciones con el mismo inventario de controles, reduciendo la carga de compliance duplicado.

    Para los equipos de gobernanza de datos en la región, el mensaje es operativo: si el catálogo de datos no incluye campos de clasificación de sensibilidad y asignación de data owner por dominio, ese es el primer gap a cerrar — no porque lo pida el CISO, sino porque sin esa base cualquier política de control preventivo queda sin sustento.