Autor: Redacción

  • IA en banca: por qué datos, privacidad y gobernanza frenan la transformación

    IA en banca: por qué datos, privacidad y gobernanza frenan la transformación

    Los CEOs del sector financiero reconocen el potencial transformador de la inteligencia artificial en la banca, pero señalan que la gobernanza de datos, la privacidad y la calidad de la información siguen siendo los obstáculos más difíciles de resolver. Sin datos confiables y marcos sólidos de gobierno, la IA en banca no escala: automatiza el caos.

    La promesa de la IA en servicios financieros —desde la detección de fraude hasta la personalización crediticia y la atención automatizada al cliente— lleva años circulando en las salas de directorio. Lo que está cambiando es el diagnóstico de los propios líderes sobre por qué esa promesa no se materializa a la velocidad esperada. Según se informó en declaraciones de CEOs del sector bancario, los tres cuellos de botella recurrentes son la calidad de los datos internos, las exigencias de privacidad y la ausencia de marcos de gobernanza que conecten ambos planos.

    El dato sucio como límite estructural de la IA bancaria

    Un modelo de IA entrena sobre los datos que recibe. Si esos datos tienen inconsistencias de origen, duplicaciones entre sistemas core y periféricos, o metadatos sin propietario definido, el modelo hereda esos problemas y los amplifica. En la industria financiera, donde coexisten sistemas legacy de los años 80 con plataformas cloud modernas, la fragmentación del dato no es una excepción: es la norma. El DAMA-DMBOK identifica la calidad del dato como uno de las diez áreas de conocimiento centrales en gobernanza, y en banca esa dimensión se vuelve crítica antes de cualquier proyecto de IA: si no hay data stewards definidos por dominio (clientes, productos, transacciones, riesgo), nadie puede certificar qué dato alimenta qué modelo.

    El Marco de Capacidades de Gestión de Datos del EDM Council (DCAM) establece que la capacidad 8 —gestión de calidad del dato— es prerequisito para habilitar analítica avanzada. La mayoría de los bancos medianos de América Latina operan por debajo de ese umbral sin saberlo, porque nunca realizaron una evaluación formal de madurez. Implementar IA sobre esa base equivale a construir sobre arena.

    Privacidad: la regulación que no es opcional en ninguna jurisdicción bancaria de la región

    Los bancos operan con datos personales sensibles por definición: ingresos, comportamiento de gasto, historial crediticio, identidad biométrica. En América Latina, ese universo de datos está cubierto —con distintos niveles de madurez regulatoria— por la Ley General de Protección de Datos de Brasil (LGPD), la Ley 25.326 de Argentina y su autoridad de aplicación AAIP, la Ley Federal de Protección de Datos Personales en Posesión de los Particulares de México (LFPDPPP), y la Ley 1581 de Colombia, entre otras. Cualquier sistema de IA que procese esos datos para fines distintos a los originalmente declarados al titular puede configurar una infracción, incluso si el resultado es técnicamente correcto.

    El riesgo específico en IA bancaria es el uso de datos de clientes para entrenar modelos sin base legal suficiente o sin mecanismos de exclusión disponibles para el titular. Brasil, a través de la ANPD, ya ha publicado notas técnicas sobre el uso legítimo de datos personales en sistemas automatizados. Argentina avanza en la modernización de la Ley 25.326, con un proyecto que incorpora disposiciones específicas sobre decisiones automatizadas con impacto en personas. Las instituciones que no documentan hoy qué datos alimentan qué modelos enfrentarán mañana solicitudes de acceso (DSAR) que no podrán responder.

    Gobernanza de IA: cuándo aplica y cuándo la banca no puede eludirla

    La gobernanza de IA en el sector financiero aplica en cualquier caso donde un sistema automatizado tome o asista decisiones con impacto directo sobre un cliente: aprobación o rechazo de crédito, clasificación de riesgo, detección de fraude con bloqueo de cuenta, o asignación diferenciada de productos. En todos esos escenarios, los marcos regulatorios emergentes —incluida la orientación del Comité de Basilea sobre riesgo operacional y el AI Act de la Unión Europea, que impacta a bancos con operaciones en Europa— exigen explicabilidad, supervisión humana y registros de auditoría. Un banco que no puede explicar por qué un modelo rechazó un crédito no cumple con la mayoría de las regulaciones de protección al consumidor financiero vigentes en la región.

    Lo que no aplica es la confusión entre gobernanza de datos y gobernanza de IA. Son capas distintas: la primera regula el activo (el dato); la segunda, el sistema que lo procesa. Ambas son necesarias. Un banco puede tener datos bien gobernados y aun así desplegar modelos sin accountability. El NIST AI Risk Management Framework (AI RMF) ofrece una estructura práctica para mapear riesgos por tipo de sistema y contexto de uso, adaptable al entorno regulatorio latinoamericano.

    Lo que los bancos de LATAM deben resolver antes de escalar

    En la región, la adopción de IA en banca avanza a distintas velocidades. Los bancos digitales nacidos post-2015 —Nubank en Brasil, Uala en Argentina, Mercado Pago en toda la región— parten de arquitecturas de datos modernas que facilitan la trazabilidad. Los bancos tradicionales, en cambio, enfrentan el costo y la complejidad de modernizar el dato antes de poder usarlo en producción con IA. El Banco Central de Brasil, mediante resoluciones sobre open finance, ya impone estándares de calidad e interoperabilidad que funcionan como palanca de modernización de datos: los bancos que reportan al BCB bajo esos esquemas están, en la práctica, construyendo capacidades de data lineage —trazabilidad de origen y transformación del dato— que son el primer requisito de cualquier IA auditable.

    En México, la Comisión Nacional Bancaria y de Valores (CNBV) ha incorporado criterios de gestión de riesgos tecnológicos que incluyen sistemas algorítmicos, aunque sin un marco específico de IA. En Argentina, el BCRA requiere planes de continuidad y gestión de modelos bajo la Comunicación A 7724, lo que obliga a documentar el ciclo de vida de los modelos aunque no se llame explícitamente gobernanza de IA. Esas regulaciones sectoriales existentes son el punto de entrada real para estructurar la gobernanza, no un obstáculo adicional.

    Para profundizar en los estándares aplicables, el NIST AI RMF está disponible en ai.nist.gov y el marco DCAM del EDM Council en edmcouncil.org; ambos ofrecen herramientas de autoevaluación adaptables al contexto financiero latinoamericano.

  • Atlantic Dama encalla en San Antonio Este: sin vínculo con datos

    Atlantic Dama encalla en San Antonio Este: sin vínculo con datos

    La noticia sobre el reflotamiento del buque Atlantic Dama en el Puerto de San Antonio Este, publicada por el portal Data Portuaria el 9 de agosto de 2026, no guarda relación con gobernanza de datos, privacidad, inteligencia artificial ni regulación digital. El artículo fue indexado por error bajo la fuente DAMA/DMBOK/CDMC en Google News.

    El evento describe un incidente de navegación marítima en aguas argentinas: el buque Atlantic Dama encalló en el Puerto de San Antonio Este y fue posteriormente reflotado según informó el portal especializado en logística portuaria Data Portuaria. Se trata de un suceso de índole operativa y marítima sin contenido relevante para las verticales editoriales de DataTrends LATAM —gobernanza de datos, privacidad, Legal AI o regulación digital.

    Por qué esta nota no se publica en DataTrends LATAM

    DataTrends LATAM cubre exclusivamente temas de gobernanza de datos corporativa, protección de datos personales, regulación de inteligencia artificial y marcos normativos digitales en América Latina. Un incidente de encallamiento marítimo —sin ángulo de datos, privacidad ni regulación tecnológica— queda fuera del alcance editorial del medio. La coincidencia de nombres entre “Data Portuaria” y las siglas DAMA (Data Management Association) generó una indexación errónea en el feed de Google News monitoreado.

    Acción correctiva: filtro de fuentes en el pipeline de ingestión

    Este caso ilustra un problema concreto de calidad en pipelines de monitoreo de medios: la coincidencia semántica superficial entre términos —”Data Portuaria” vs. DAMA International— puede contaminar feeds de inteligencia editorial si no existen filtros de relevancia temática en la etapa de ingestión. Los equipos que utilizan Google News RSS o herramientas similares para monitoreo de regulación y gobernanza de datos deben implementar al menos un nivel de clasificación por entidad y categoría temática antes de escalar contenido a revisión humana.

    La nota no se publica; el feed de monitoreo será ajustado para excluir coincidencias por nombre de fuente sin validación temática.

  • CRASA debatió gobernanza de datos e IA en su comité de política regional

    CRASA debatió gobernanza de datos e IA en su comité de política regional

    El Comité Legal y de Política de CRASA —la asociación de reguladores de telecomunicaciones del sur y este de África— abrió formalmente una sesión de trabajo dedicada a inteligencia artificial, gobernanza de datos y regulación regional de las TIC. El encuentro señala un punto de inflexión: los reguladores de una de las regiones con mayor crecimiento de infraestructura digital del mundo reconocen que sus marcos normativos no están diseñados para los ecosistemas de datos actuales. Para América Latina, que enfrenta el mismo desfasaje entre velocidad tecnológica y capacidad regulatoria, el movimiento africano ofrece una referencia metodológica concreta.

    CRASA y los 16 reguladores que coordinan el sur de África

    CRASA (Communications Regulators’ Association of Southern Africa) agrupa a las autoridades regulatorias de telecomunicaciones de 16 países del sur y este del continente africano. Su Comité Legal y de Política actúa como espacio de armonización normativa: cuando ese comité abre una sesión específica sobre IA y gobernanza de datos, no está explorando tendencias académicas sino evaluando si los instrumentos regulatorios existentes —licencias, obligaciones de reporte, regímenes de acceso a infraestructura— son suficientes para gobernar flujos de datos transfronterizos, sistemas automatizados de decisión y modelos de IA desplegados por operadores con presencia regional. Según se informó, la agenda incluyó el análisis del estado de avance de los marcos nacionales frente a los requerimientos de la economía digital.

    Por qué un comité de telcos discute gobernanza de datos en 2025

    La convergencia entre regulación de telecomunicaciones y gobernanza de datos no es una anomalía: es la consecuencia lógica de que los operadores de redes son, simultáneamente, los mayores recolectores de datos de comportamiento, geolocalización y comunicaciones de sus países. Cuando un regulador TIC fija condiciones para una licencia de operación, está —aunque no lo nombre explícitamente— estableciendo quién tiene acceso a qué datos, bajo qué condiciones y con qué obligaciones de retención. El Comité de CRASA está haciendo explícito algo que en muchas jurisdicciones permanece implícito: la regulación de infraestructura digital es, en el fondo, una forma de gobernanza de datos.

    Desde la perspectiva del DAMA-DMBOK, esto equivale a reconocer que el “data ownership” no puede resolverse solo dentro de las organizaciones —requiere un marco externo que defina derechos, responsabilidades y mecanismos de control a nivel sectorial y regional. Los reguladores africanos están intentando construir ese marco colectivamente, algo que en América Latina todavía se hace de manera fragmentada y fundamentalmente reactiva.

    Brasil, México y Colombia: tres velocidades en el mismo problema

    América Latina no parte de cero. Brasil cuenta con la Lei Geral de Proteção de Dados (LGPD, Lei nº 13.709/2018) y con la ANPD como autoridad de aplicación, que en 2024 emitió regulaciones sobre agentes de tratamiento y bases legales. Sin embargo, la ANPD no tiene mandato explícito sobre gobernanza corporativa de datos más allá de lo que impone la LGPD: no puede exigir que una empresa implemente un catálogo de datos, defina data stewards o mantenga linaje documentado, a menos que esa ausencia derive en una violación de los principios de seguridad o minimización de la ley.

    México opera bajo la Ley Federal de Protección de Datos Personales en Posesión de los Particulares (LFPDPPP, 2010) y el INAI como regulador, con un marco centrado en derechos ARCO que tiene escasa incidencia en cómo las empresas organizan internamente sus arquitecturas de datos. Colombia, por su parte, cuenta con la Ley 1581 de 2012 y la Superintendencia de Industria y Comercio (SIC), que ha avanzado en orientaciones sobre transferencias internacionales, pero aún no emitió guías técnicas sobre gestión del ciclo de vida del dato equivalentes a las que se esperan de un marco CDMC. El resultado es que las tres jurisdicciones más grandes de la región tienen marcos de privacidad razonablemente maduros pero marcos de gobernanza de datos corporativa virtualmente inexistentes desde el ángulo regulatorio.

    Lo que los CDOs de la región pueden tomar del modelo CRASA

    El valor del enfoque de CRASA no está en sus resoluciones —que todavía no se conocen públicamente— sino en su método: un comité sectorial que evalúa sistemáticamente si los instrumentos regulatorios existentes son adecuados para los activos de datos que los operadores manejan. Ese ejercicio de mapeo —”¿tenemos cobertura normativa para este tipo de dato, este tipo de sistema, este tipo de flujo transfronterizo?”— es exactamente lo que los marcos de gobernanza maduros como DCAM (Data Capability Assessment Model del EDM Council) proponen hacer a nivel organizacional.

    Un CDO en Argentina, Brasil o Colombia puede tomar ese modelo y aplicarlo internamente: mapear las capacidades de gobernanza existentes contra los requerimientos que la regulación sectorial ya impone —comunicaciones al BCRA bajo la Comunicación A 8073 para bancos argentinos, reportes de incidentes a la ANPD bajo el artículo 48 de la LGPD, o notificaciones a la SIC en Colombia— e identificar las brechas reales. Ese mapeo es el punto de partida para un roadmap de gobernanza que no sea aspiracional sino jurisdiccionalmente anclado. La semana que viene es una buena fecha para abrir ese inventario: quién es el data steward de cada dominio regulado, qué linaje está documentado, qué no.

    Qué monitorear: la agenda regulatoria TIC en LATAM durante el segundo semestre de 2025

    El movimiento de CRASA coincide con una ventana activa en la región. En Chile, la Ley 21.719 de Protección de Datos Personales —promulgada en diciembre de 2024 y con entrada en vigor escalonada— incluye obligaciones de seguridad y gobernanza que van más allá de los marcos anteriores. En Perú, la Ley 29733 está bajo revisión legislativa. En Brasil, la ANPD tiene en su agenda la regulación de decisiones automatizadas. Ninguno de estos procesos cuenta aún con un comité equivalente al de CRASA —un espacio de armonización técnica entre reguladores— lo que hace que el intercambio de experiencias entre países siga dependiendo de foros informales o de la intermediación de organismos como la CEPAL o la OEA.

    Nuestro análisis

    La sesión de CRASA importa menos por lo que resuelva que por lo que institucionaliza: la gobernanza de datos como agenda regulatoria sectorial, no solo como obligación de privacidad individual. Esa distinción es crucial. Mientras los marcos latinoamericanos siguen atando gobernanza de datos a derechos de titulares —un enfoque necesario pero insuficiente—, otros bloques regionales están construyendo la capa de gobernanza corporativa e interoperabilidad que permite que esos derechos sean ejercibles en la práctica. Una empresa que no sabe qué datos tiene, dónde están y quién es responsible de cada dominio no puede responder un DSAR en 30 días ni notificar una brecha en 72 horas. El orden lógico es: gobernanza primero, cumplimiento como resultado. Eso es lo que CRASA, al menos en el papel, está intentando formalizar.

    La pregunta concreta para los equipos de datos en la región: ¿puede su organización responder hoy, sin buscar en carpetas, quién es el data steward de cada sistema que toca datos regulados? Si la respuesta es no, ese es el primer gap que documentar.

  • Meta censura salud reproductiva: EFF presenta caso ante la Junta de Supervisión

    Meta censura salud reproductiva: EFF presenta caso ante la Junta de Supervisión

    La Electronic Frontier Foundation presentó un comentario público ante la Junta de Supervisión de Meta documentando un patrón sistemático: las plataformas del grupo —Instagram en particular— eliminan contenido legítimo sobre salud reproductiva al confundirlo con tráfico de medicamentos. El caso en análisis involucra una publicación de Instagram sobre medicamentos de prescripción durante el embarazo y el parto.

    El problema no es anecdótico. A través del proyecto Stop Censoring Abortion, la EFF recopiló cerca de cien testimonios de proveedores de salud, clínicas, educadores, investigadores y advocates cuyo contenido había sido eliminado o suprimido por plataformas de redes sociales. El denominador común: en casi todos los casos documentados, las publicaciones censuradas no violaban las reglas declaradas de las plataformas.

    La política de bienes restringidos de Meta y su aplicación sobre contenido médico legítimo

    Meta invoca con frecuencia su Política de Bienes y Servicios Restringidos, que prohíbe intentos de comprar, vender, intercambiar, donar o solicitar medicamentos farmacéuticos. El problema es que el sistema de moderación no distingue entre esa conducta prohibida y la discusión factual o educativa sobre esos mismos medicamentos. Según la documentación de la EFF, el contenido eliminado consistía abrumadoramente en información clínica, experiencias personales con la atención médica y datos para acceder a servicios legales, no en ofertas comerciales de fármacos.

    Los efectos concretos fueron significativos. La Miscarriage+Abortion Hotline tuvo su cuenta de Instagram restringida y publicaciones eliminadas a pesar de que su actividad se limitaba a informar sobre cómo obtener medicación de manera legal. Red River Women’s Clinic y el centro de investigación RISE de la Universidad de Emory enfrentaron situaciones similares. Se documentaron además bajas repentinas de cuentas, desranqueo de perfiles sin notificación y procesos de apelación que, según la EFF, rara vez llegaban a una resolución concreta.

    Cuándo aplica la restricción y cuándo no: el límite que los sistemas automáticos no logran trazar

    La política de Meta aplica —al menos en su formulación textual— a transacciones comerciales de medicamentos no autorizadas. No aplica, en principio, a la información médica de acceso público, a la educación sanitaria ni a los testimonios personales sobre experiencias de salud. El fallo documentado por la EFF ocurre en la capa de detección: los sistemas automáticos identifican palabras clave o patrones asociados a fármacos específicos sin evaluar el contexto de la publicación. El resultado es lo que la EFF denomina sobre-aplicación sistémica: el contenido con más probabilidad de ser eliminado es, paradójicamente, el que proviene de actores institucionales con perfiles verificables y contenido clínicamente preciso.

    Este tipo de sobre-moderación no es un error técnico menor. Cuando una clínica pierde su cuenta de Instagram sin posibilidad real de apelar, se interrumpe un canal de acceso a información que para muchas personas —especialmente en contextos de baja escolaridad o zonas rurales— puede ser el único disponible. La EFF sostiene que la Junta de Supervisión de Meta tiene ante sí la oportunidad de establecer un estándar claro: hablar sobre medicamentos no equivale a venderlos.

    El régimen de moderación de contenido y los derechos digitales en América Latina

    En América Latina, la tensión entre moderación de contenido y libertad de expresión en salud reproductiva adquiere dimensiones adicionales. Varios países de la región —entre ellos Argentina, Ecuador, Honduras y El Salvador— tienen marcos legales restrictivos sobre el aborto, lo que genera incentivos para que los sistemas de moderación sean aún más agresivos con contenido relacionado. En México, donde la Ley Federal de Protección de Datos Personales en Posesión de los Particulares (LFPDPPP) regula el tratamiento de datos de salud como categoría sensible, la eliminación arbitraria de cuentas de salud también plantea interrogantes sobre el tratamiento que las plataformas dan a la información que recopilan antes de eliminar el contenido. En Brasil, la Autoridade Nacional de Proteção de Dados (ANPD) ha comenzado a observar con mayor atención las prácticas de las plataformas sobre datos sensibles, categoría que bajo la Lei Geral de Proteção de Dados (LGPD) incluye explícitamente datos sobre salud. La sobre-moderación, en este marco, no es solo un problema de libertad de expresión: puede implicar tratamiento indebido de datos personales sensibles.

    La Junta de Supervisión de Meta es un mecanismo de rendición de cuentas de alcance global. Sus decisiones se aplican a todas las plataformas del grupo en todos los países donde operan. Eso significa que un fallo que establezca criterios más precisos para distinguir información médica legítima de transacciones comerciales prohibidas tendría efecto directo sobre millones de usuarios latinoamericanos.

    El comentario completo de la EFF ante la Junta de Supervisión de Meta, así como los testimonios recopilados a través del proyecto Stop Censoring Abortion, están disponibles en eff.org/pages/stop-censoring-abortion. La decisión de la Junta sobre el caso de medicamentos durante el embarazo aún está pendiente.

  • CISA advierte sobre Gunra Ransomware: doble extorsión contra infraestructura crítica

    CISA advierte sobre Gunra Ransomware: doble extorsión contra infraestructura crítica

    La Agencia de Ciberseguridad e Infraestructura de Estados Unidos (CISA) emitió el 10 de agosto de 2026 una alerta formal sobre Gunra, un ransomware-as-a-service (RaaS) activo desde 2025 que opera bajo un esquema de doble extorsión: cifra los datos de sus víctimas y amenaza con publicarlos en un sitio de filtraciones dedicado si no se paga el rescate. Los sectores afectados incluyen gobierno, infraestructura crítica y otras organizaciones.

    Gunra surgió como variante independiente en 2025 y escaló a modelo RaaS a lo largo de 2026, lo que significa que sus operadores reclutan afiliados externos que ejecutan los ataques a cambio de una porción del rescate cobrado. Este modelo reduce la barrera técnica de entrada para actores maliciosos y amplía significativamente la superficie de ataque. La alerta de CISA fue publicada bajo el programa #StopRansomware, que sistematiza avisos técnicos sobre amenazas activas para facilitar la respuesta de organizaciones públicas y privadas.

    Doble extorsión: cifrado más exfiltración confirmada

    El vector que distingue a Gunra es la combinación de cifrado de datos con exfiltración previa y amenaza de publicación. Los afiliados no solo inutilizan los sistemas de la víctima: antes de activar el cifrado, extraen información sensible y la alojan en un dedicated leak site (DLS) propio. Esto convierte cada ataque en un incidente de privacidad potencial, independientemente de si la organización logra restaurar sus sistemas desde respaldos. Según se informó en la alerta de CISA, los objetivos prioritarios son entidades gubernamentales e infraestructura crítica, categorías que en América Latina incluyen organismos de salud pública, energía, agua y sistemas financieros regulados.

    Datos confirmados

    • Gunra apareció por primera vez como variante de ransomware en 2025.
    • La expansión a modelo RaaS se confirmó en 2026.
    • Opera con doble extorsión: cifrado + publicación de datos exfiltrados en DLS propio.
    • Sectores objetivo declarados: gobierno, infraestructura crítica y otras organizaciones.
    • La alerta fue emitida por CISA el 10 de agosto de 2026 bajo el programa #StopRansomware.

    La alerta de CISA no detalla el número de víctimas confirmadas ni especifica países afectados fuera de Estados Unidos. Tampoco se informó el monto promedio de rescate exigido ni los vectores de acceso inicial utilizados por los afiliados. Estos datos permanecen sin confirmar al cierre de esta nota.

    Para las organizaciones en América Latina, el esquema RaaS de Gunra tiene implicancias directas en materia de notificación de brechas. En Brasil, la Lei Geral de Proteção de Dados (LGPD) obliga a notificar a la Autoridade Nacional de Proteção de Dados (ANPD) en un plazo razonable cuando hay exfiltración de datos personales. En Argentina, la Ley 25.326 y las disposiciones complementarias de la AAIP establecen la obligación de reportar incidentes de seguridad. En México, el INAI exige notificación bajo la LFPDPPP cuando datos personales bajo custodia de responsables privados son comprometidos. En todos estos casos, el modelo de doble extorsión activa automáticamente las obligaciones de reporte, incluso si la organización decide no pagar el rescate: la exfiltración ya ocurrió.

    Las organizaciones en la región con infraestructura crítica o datos gubernamentales bajo custodia deben verificar hoy si sus planes de respuesta a incidentes incluyen protocolos de notificación a autoridades de protección de datos ante exfiltración confirmada, no solo ante cifrado.

  • IA sin gobernanza de datos: el problema de integración que nadie quiere ver

    IA sin gobernanza de datos: el problema de integración que nadie quiere ver

    Desplegar inteligencia artificial sobre datos sin gobierno es repetir, a mayor escala y velocidad, el mismo error que organizaciones latinoamericanas han cometido con cada ola tecnológica anterior: integrar primero, ordenar después. El resultado predecible es un sistema que amplifica el caos en lugar de reducirlo.

    Cuando una organización conecta un modelo de lenguaje o un sistema de analítica predictiva a sus repositorios internos sin haber definido quién es responsable de cada dato, qué calidad tiene y bajo qué reglas circula, no está adoptando inteligencia artificial — está construyendo un conducto de alta velocidad hacia sus problemas de datos más viejos. La IA no genera orden: consume el que existe. Si el orden no existe, el modelo lo hace visible de la peor manera posible: en producción, frente al cliente, o frente al regulador.

    Por qué la IA expone brechas de gobernanza que los sistemas legacy ocultaban

    Los sistemas transaccionales tradicionales toleran datos duplicados, inconsistentes o sin propietario definido porque operan con reglas fijas y flujos predecibles. Un ERP con mala calidad de datos sigue funcionando dentro de sus parámetros. Un modelo de IA entrenado o alimentado con esos mismos datos, en cambio, generaliza las inconsistencias: las aprende, las replica y las escala a toda decisión que toque. Lo que antes era un problema de datos silenciado por la rigidez del sistema, ahora se convierte en un comportamiento del modelo difícil de depurar y más difícil aún de explicar ante una auditoría.

    El marco DAMA-DMBOK identifica diez áreas de conocimiento en gobernanza de datos. Las más frecuentemente ausentes en proyectos de IA corporativa en la región son precisamente las más críticas para su funcionamiento: calidad de datos (Data Quality), gestión de metadatos (Metadata Management) y lineaje (Data Lineage). Sin saber de dónde viene un dato, qué transformaciones sufrió y quién lo validó, es imposible auditar por qué un modelo tomó una decisión determinada — requisito que ya no es opcional en ninguna jurisdicción con regulación de IA o de datos personales activa.

    El rol del data steward antes del primer prompt

    En organizaciones con gobernanza madura, el data steward — responsable operativo de un dominio de datos específico — es quien certifica que un conjunto de datos es apto para un uso determinado antes de que ese uso ocurra. En proyectos de IA, esa certificación debería preceder al entrenamiento o a la conexión del modelo a fuentes internas. Sin embargo, según el EDM Council, menos del 30% de las organizaciones globales que han iniciado proyectos de IA generativa en entornos productivos contaban con ownership formal de datos en los dominios involucrados al momento del despliegue, según se informó en su evaluación CDMC de 2024.

    El patrón es conocido en la región: el equipo de datos construye el pipeline, el equipo de negocio aprueba el caso de uso, y la función de gobernanza — cuando existe — es informada después. Bob Seiner, referente de la metodología Non-Invasive Data Governance, describe este modelo como “gobernanza reactiva”: se activa cuando algo sale mal, no cuando se define qué puede salir mal. En proyectos de IA, el costo de esa reactividad es estructuralmente más alto porque los errores se propagan a velocidades que los procesos manuales de remediación no pueden seguir.

    México y el costo regulatorio de no gobernar antes de desplegar

    México opera bajo la Ley Federal de Protección de Datos Personales en Posesión de los Particulares (LFPDPPP) y su autoridad de control, el INAI, ha emitido lineamientos sobre el uso de datos personales en sistemas automatizados. Si un modelo de IA toma decisiones que afectan a personas físicas — scoring crediticio, selección de candidatos, segmentación de pacientes — y fue alimentado con datos personales sin el consentimiento adecuado o sin una base legal documentada, la organización enfrenta responsabilidad bajo la ley vigente, independientemente de si el modelo “funciona bien” en términos técnicos. La ausencia de linaje documental hace imposible demostrar cumplimiento en una auditoría del INAI.

    El escenario no es exclusivo de México. En Brasil, la LGPD (Lei Geral de Proteção de Dados) exige base legal para cada tratamiento de datos personales, incluidos los automatizados, y la ANPD ha señalado explícitamente el uso de IA como área de supervisión prioritaria para 2025-2026. En Argentina, la Ley 25.326 y la AAIP enfrentan un escenario similar con menor capacidad sancionatoria formal, pero con presión creciente desde la esfera judicial. En todos estos casos, un catálogo de datos con clasificación de sensibilidad y linaje documentado es la primera línea de defensa — no el cifrado, no el pentesting, sino saber qué datos tiene la organización y quién responde por ellos.

    Cuándo aplica la gobernanza previa — y cuándo ya es tarde

    La gobernanza de datos como prerrequisito de IA aplica en cualquier proyecto que involucre datos internos de la organización, datos de clientes, o datos sujetos a regulación sectorial — es decir, prácticamente todos los casos de uso empresarial relevantes. No aplica, o aplica en menor medida, a modelos completamente aislados que operan sobre datos sintéticos o sobre conjuntos públicos sin datos personales, que representan una fracción marginal de los proyectos reales. La pregunta que un CDO debe hacer antes de aprobar el presupuesto de cualquier iniciativa de IA no es “¿tenemos los datos?” sino “¿sabemos qué son esos datos, quién los posee y bajo qué condiciones pueden usarse?”. Si la respuesta a alguna de esas tres preguntas es incierta, el proyecto tiene un problema de gobernanza disfrazado de problema de ingeniería.

    Un CDO que enfrenta esta situación en su organización puede tomar tres pasos concretos antes de que el siguiente proyecto de IA entre a producción: primero, mapear los dominios de datos que alimentarán el sistema e identificar si tienen un data steward asignado con accountability formal; segundo, ejecutar un perfil de calidad de datos sobre esas fuentes con métricas de completitud, consistencia y unicidad — herramientas como Great Expectations, Monte Carlo o incluso dbt tests permiten hacerlo sin infraestructura adicional; tercero, documentar el linaje desde la fuente hasta el modelo en el catálogo de datos corporativo, de modo que cualquier auditor interno o externo pueda reconstruir el recorrido del dato sin depender de quien lo construyó. Estos tres pasos no garantizan un modelo perfecto, pero sí una organización que puede defender sus decisiones.

    La gobernanza de datos no es el freno de la adopción de IA: es la condición para que esa adopción sea sostenible. Las organizaciones que lo descubran después del primer incidente regulatorio habrán pagado un precio innecesario por una lección que ya estaba disponible.

  • IA y protección de datos en LATAM: el mapa regulatorio de 2025

    IA y protección de datos en LATAM: el mapa regulatorio de 2025

    América Latina atraviesa la fase más activa de su historia regulatoria en materia de inteligencia artificial y protección de datos personales. Según se informó desde la IAPP, los países de la región acumulan avances simultáneos en implementación normativa que, por primera vez, apuntan a converger con estándares internacionales. El mapa ya no es el de hace tres años: hay leyes en vigor, autoridades operativas y, en algunos casos, primeras sanciones.

    El fenómeno no es uniforme. Mientras Brasil consolida la Autoridade Nacional de Proteção de Dados (ANPD) como referencia regional —con resoluciones sobre bases legales, evaluaciones de impacto y, desde 2024, guías específicas para el uso de IA en tratamiento de datos personales—, otros países todavía debaten si su marco de privacidad vigente es suficiente para cubrir los riesgos que introducen los sistemas automatizados de toma de decisiones. Esa brecha entre vanguardia y rezago es el dato estructural de la región en este momento.

    Brasil y Colombia lideran la implementación con instrumentos concretos

    Brasil es el caso de mayor desarrollo institucional. La LGPD (Lei Geral de Proteção de Dados, Lei nº 13.709/2018) tiene ya jurisprudencia administrativa acumulada, y la ANPD avanza en su agenda regulatoria con énfasis en tres frentes: tratamiento de datos de menores, transferencias internacionales y —el más relevante para el momento actual— decisiones automatizadas bajo el artículo 20 de la ley, que reconoce el derecho del titular a solicitar revisión humana de decisiones tomadas exclusivamente por algoritmos. La ANPD publicó en 2024 un documento de referencia sobre el tema que, según se informó, está siendo revisado a la luz del avance del marco europeo de IA.

    Colombia, por su parte, opera bajo la Ley 1581 de 2012 y su decreto reglamentario, con la Superintendencia de Industria y Comercio (SIC) como autoridad de control. La SIC ha emitido circulares sobre el uso de datos en sistemas de IA y, en 2024, presentó lineamientos para el tratamiento de datos en modelos de lenguaje de gran escala. No es legislación vinculante todavía, pero establece una posición institucional que anticipa regulación formal. Colombia también participó activamente en las discusiones del marco interamericano de IA impulsado por la OEA.

    Argentina y México: marcos de privacidad que preceden a la IA y muestran sus límites

    Argentina tiene la Ley 25.326 de Protección de Datos Personales —una de las más antiguas de la región, sancionada en el año 2000— y una reforma pendiente desde hace años que el Congreso no ha logrado aprobar. La Agencia de Acceso a la Información Pública (AAIP) emitió en 2023 recomendaciones sobre IA y datos personales, pero sin fuerza normativa vinculante. El problema concreto es que el artículo 20 de la ley vigente limita parcialmente las decisiones automatizadas, pero fue redactado antes de que existieran los sistemas actuales de machine learning: su aplicación a modelos fundacionales es, en el mejor caso, interpretativa. Una reforma legislativa que modernice ese articulado —con estándares explícitos de explicabilidad, auditoría y evaluación de impacto— sigue siendo la deuda más clara del ecosistema argentino.

    México opera bajo la Ley Federal de Protección de Datos Personales en Posesión de los Particulares (LFPDPPP, 2010) y su equivalente para el sector público (LPDPPSO, 2017), con el INAI como autoridad de control. El instituto ha publicado guías sobre IA y datos personales, pero la discusión regulatoria específica sobre sistemas de IA de alto riesgo —al estilo del AI Act europeo— no tiene todavía un vehículo legislativo propio. El INAI enfrenta además un escenario institucional complejo: su presupuesto y autonomía han sido objeto de debate político, lo que genera incertidumbre sobre su capacidad de enforcement en temas emergentes.

    El AI Act europeo como referencia, no como modelo de copia directa

    Varios países de la región toman el Reglamento de Inteligencia Artificial de la Unión Europea (AI Act, Reglamento UE 2024/1689, en vigor desde agosto de 2024) como punto de partida para sus propios marcos. La lógica es comprensible: es el instrumento más desarrollado disponible, con clasificación por niveles de riesgo, prohibiciones específicas y requisitos de transparencia. Sin embargo, los equipos legales que operan en LATAM deberían evitar una trasposición mecánica. Las estructuras de enforcement de la región son distintas —autoridades de privacidad con recursos limitados, ausencia de autoridades sectoriales de IA en la mayoría de los países—, y los sectores de mayor riesgo no son idénticos: el uso de IA en crédito informal, en sistemas de bienestar social y en procesos migratorios tiene una escala y una urgencia diferentes a las del contexto europeo.

    Lo que sí es directamente aplicable es el principio de evaluación de impacto en protección de datos (EIPD/DPIA) para sistemas de IA que traten datos personales a escala. Tanto la LGPD brasileña como la LFPDPPP mexicana y la Ley 1581 colombiana contienen bases para exigir ese análisis, aunque con distintos niveles de desarrollo reglamentario.

    Chile y Perú: reformas en curso con cronogramas definidos

    Chile aprobó en 2024 su nueva Ley de Protección de Datos Personales (Ley 21.719), que moderniza el marco vigente desde 1999 y crea el Consejo para la Transparencia con funciones ampliadas de control. La ley incluye disposiciones sobre decisiones automatizadas y establece plazos de implementación progresiva hasta 2026. Es el avance legislativo más significativo de la región en los últimos dos años y pone a Chile en condiciones de negociar adecuación con la Unión Europea. Perú, por su parte, opera bajo la Ley 29733 con la Autoridad Nacional de Protección de Datos (ANPD-Perú) adscrita al Ministerio de Justicia; hay un proyecto de reforma en discusión que incorpora elementos de la economía digital, pero sin cronograma aprobado.

    Qué monitorear en los próximos seis meses

    Los hitos regulatorios más relevantes para el segundo semestre de 2025 y primer trimestre de 2026 incluyen: la resolución de la ANPD brasileña sobre decisiones automatizadas, que según se informó podría publicarse antes de fin de año; la entrada en vigor progresiva de la Ley 21.719 chilena; y el avance —o estancamiento— de la reforma a la Ley 25.326 en el Congreso argentino. A nivel regional, el proceso de elaboración de un marco interamericano de IA en el seno de la OEA es un espacio a seguir, aunque sus productos son de naturaleza no vinculante.

    Nuestro análisis

    La convergencia regulatoria en LATAM es real pero asimétrica. Brasil y Chile tienen marcos técnicamente robustos con autoridades que pueden hacer enforcement. Colombia construye posición institucional sin legislación específica de IA todavía. Argentina y México tienen leyes de privacidad que funcionan como red de contención, pero con evidentes limitaciones para capturar los riesgos de los sistemas de IA actuales. Para las empresas que operan en múltiples jurisdicciones de la región, la estrategia de “cumplir con LGPD y replicar” es un punto de partida razonable, pero insuficiente: las especificidades de cada marco —especialmente en decisiones automatizadas, transferencias internacionales y datos sensibles— requieren análisis jurisdicción por jurisdicción. El riesgo de enforcement cruzado es bajo hoy; en 24 meses, con autoridades más consolidadas, ese cálculo cambia.

    La pregunta que los equipos legales y de datos deberían estar respondiendo ahora no es si su empresa cumple con la regulación vigente, sino si su arquitectura de gobernanza está preparada para las obligaciones que llegan en 2026.

  • DFS de Nueva York multa a Order Express con USD 250.000 por fallos en ciberseguridad

    DFS de Nueva York multa a Order Express con USD 250.000 por fallos en ciberseguridad

    El Departamento de Servicios Financieros de Nueva York (DFS) anunció el 5 de agosto de 2026 un acuerdo de USD 250.000 con Order Express, Inc., una transmisora de dinero con licencia, por incumplimientos a la regulación de ciberseguridad 23 NYCRR Part 500. La sanción refuerza un patrón creciente de enforcement que el regulador neoyorquino viene consolidando desde 2023 y que tiene implicancias directas para los operadores de servicios de pago con presencia o corresponsalía en América Latina.

    La Superintendente Actuante Kaitlin Asrow fue quien formalizó el anuncio. Según el comunicado oficial del DFS, los investigadores del organismo identificaron deficiencias en el programa de ciberseguridad de Order Express, aunque el texto público disponible no detalla los controles específicos que fallaron ni si hubo un incidente de seguridad que detonó la auditoría. La empresa, en su condición de money transmitter —categoría regulada que incluye remesadoras y procesadores de pagos internacionales—, estaba obligada a cumplir con los requerimientos técnicos y organizacionales del 23 NYCRR Part 500 desde su entrada en vigor.

    23 NYCRR Part 500: el estándar que el DFS viene endureciendo desde 2023

    La regulación 23 NYCRR Part 500 del DFS es uno de los marcos de ciberseguridad sectoriales más exigentes de Estados Unidos. Establece requisitos concretos sobre evaluación de riesgos, control de acceso, cifrado de datos en tránsito y en reposo, planes de respuesta a incidentes, y la designación de un Chief Information Security Officer (CISO). En noviembre de 2023, el DFS publicó enmiendas significativas que ampliaron las obligaciones para entidades de mayor tamaño —denominadas “Class A”— e introdujeron exigencias más estrictas de notificación de incidentes: 72 horas para reportar eventos materiales de ciberseguridad y 24 horas para pagos de ransomware. Este caso con Order Express se enmarca en la fase post-enmiendas, donde el regulador intensificó las acciones de supervisión sobre entidades de menor escala que habían quedado rezagadas en la actualización de sus programas.

    Remesadoras latinoamericanas y el efecto de contagio regulatorio del DFS

    Order Express opera como transmisora de dinero, un segmento de mercado con vínculos estructurales con América Latina: México, Colombia, Guatemala, El Salvador y República Dominicana concentran los principales corredores de remesas desde Nueva York. Las empresas de este rubro que operan en o hacia la región están sujetas, del lado latinoamericano, a marcos regulatorios heterogéneos. En México, la Ley para la Transparencia y Ordenamiento de los Servicios Financieros y las disposiciones de la CNBV establecen obligaciones de seguridad de la información para entidades de transmisión de fondos, aunque sin la granularidad técnica del 23 NYCRR Part 500. En Colombia, la Superintendencia Financiera emitió la Circular Externa 007 de 2018 con requerimientos de ciberseguridad para entidades vigiladas, actualizada en 2022 para incluir gestión de riesgos en la nube. En Brasil, el Banco Central regula la seguridad cibernética de las instituciones de pago bajo la Resolução BCB nº 85/2021, que exige planes de respuesta a incidentes y pruebas periódicas. Sin embargo, ninguno de estos marcos cuenta aún con un mecanismo de enforcement tan activo y público como el del DFS neoyorquino, lo que genera una asimetría de presión regulatoria sobre los dos extremos del mismo corredor de remesas.

    USD 250.000: calibración de la multa y señal para operadores medianos

    El monto de la sanción —USD 250.000— es moderado en comparación con multas anteriores del DFS a entidades más grandes, como la aplicada a First American Title Insurance (USD 1 millón en 2023) o las sanciones millonarias a bancos globales. Eso no es accidental: el DFS ha adoptado una política de escalar las penalidades según el tamaño y la capacidad del regulado, lo que convierte este caso en una señal explícita hacia el segmento medio del mercado fintech y de servicios de pago. Para una transmisora de dinero de alcance regional, una multa de este calibre, sumada al costo de remediar las deficiencias identificadas y sostener el programa de cumplimiento, puede representar una carga operativa significativa. El efecto disuasivo apunta precisamente a ese segmento.

    Qué monitorear: notificación de incidentes y equivalencia regulatoria en LATAM

    Para los operadores latinoamericanos que mantienen corresponsalías, acuerdos de agencia o licencias en Nueva York, este caso plantea dos frentes de seguimiento inmediato. Primero, la obligación de notificación en 72 horas bajo el 23 NYCRR Part 500 enmendado ya está vigente: cualquier empresa con presencia regulada en Nueva York debe tener un proceso de escalamiento que funcione también fuera del horario hábil en la zona horaria local. Segundo, en América Latina avanzan lentamente marcos de notificación obligatoria de incidentes: Argentina no cuenta aún con un plazo unificado de notificación para el sector financiero bajo la Ley 25.326 —la autoridad de control, AAIP, puede requerirlo caso a caso—, mientras que en Brasil la LGPD establece notificación “em prazo razoável” a la ANPD, sin fijar las 72 horas como estándar fijo salvo en sectores específicos regulados por el Banco Central. La convergencia hacia plazos cortos y explícitos es el vector regulatorio más probable en los próximos dos años.

    Nuestro análisis

    El caso Order Express no es relevante por su monto —es relevante por lo que confirma: el DFS está extendiendo su enforcement hacia transmisoras de dinero medianas, un segmento históricamente con programas de ciberseguridad más débiles y mayor exposición operativa hacia mercados emergentes. Para la región, el riesgo real no es la multa en Nueva York: es que una deficiencia identificada por el DFS en un corresponsal estadounidense puede disparar revisiones en cascada por parte de supervisores locales en México, Colombia o Brasil, especialmente en un contexto donde la CNBV, la SFC y el Banco Central están afinando sus propios marcos de supervisión de ciberseguridad. Las empresas que operan corredores transfronterizos necesitan programas de ciberseguridad que puedan rendir cuentas simultáneamente ante más de un regulador, no uno construido a medida del mínimo exigible en cada jurisdicción.

    La pregunta para los operadores con licencias en múltiples jurisdicciones no es si el DFS encontrará deficiencias, sino si su programa de ciberseguridad fue diseñado para sobrevivir una auditoría cruzada entre Nueva York, Ciudad de México y Bogotá al mismo tiempo.

  • Instructure y el ataque a Canvas: lo que falló en el gobierno del dato

    Instructure y el ataque a Canvas: lo que falló en el gobierno del dato

    Instructure, la compañía detrás del sistema de gestión de aprendizaje Canvas, sufrió uno de los mayores incidentes de exposición de datos del año en Estados Unidos. El vector de entrada fue un proveedor externo, un patrón que se repite con preocupante consistencia en el sector educativo y que expone una falla estructural en la cadena de ownership del dato. Para los equipos de gobierno de datos, la pregunta relevante no es cómo ocurrió el ataque, sino qué controles de data governance habrían contenido el daño.

    Según se informó, los atacantes accedieron a los sistemas de Instructure a través de un tercero contratado, lo que desencadenó una brecha de alcance significativo que afectó a instituciones de educación superior en múltiples jurisdicciones. La naturaleza del acceso —lateral, a través de un eslabón con privilegios delegados— es característica de los ataques a cadenas de suministro de datos, donde el perímetro técnico no coincide con el perímetro de ownership del dato.

    El problema no es el ataque: es la arquitectura de confianza

    Cuando un proveedor externo puede acceder a volúmenes de datos suficientes para generar una brecha “de las más grandes del año”, el problema subyacente es de data governance, no de ciberseguridad. En términos del DAMA-DMBOK, el knowledge area de Data Security Governance establece que el acceso a datos debe estar gobernado por políticas que incluyan clasificación por sensibilidad, necesidad mínima de acceso y revisión periódica de privilegios de terceros. La pregunta que debería haber respondido un data steward antes de este incidente es: ¿qué datos puede ver este proveedor, por qué, y desde cuándo no revisamos esa autorización?

    El modelo de Non-Invasive Data Governance de Bob Seiner es particularmente relevante aquí: en entornos educativos, donde la aversión al cambio estructural es alta y los ciclos de decisión son lentos, el gobierno del dato no puede depender de grandes transformaciones organizacionales. Depende de que alguien —un data steward concreto, con nombre y responsabilidad asignada— sea accountable por cada dataset expuesto a terceros. Si ese rol no existe o no tiene visibilidad sobre los contratos de datos, el incidente de Instructure es predecible.

    Qué hace el CDO el lunes con esto

    Este caso activa al menos tres revisiones inmediatas para cualquier equipo de gobierno de datos en organizaciones con ecosistemas de proveedores:

    • Auditoría de accesos de terceros: mapear qué vendors tienen acceso a datos clasificados como sensibles o confidenciales, con qué granularidad y bajo qué contrato de procesamiento. Si el catálogo de datos no incluye esta dimensión, es el primer gap a cerrar.
    • Revisión de data lineage hacia afuera: el lineage no termina en el data warehouse interno. Los datos que fluyen a plataformas SaaS o a integraciones con terceros deben tener trazabilidad documentada. Canvas es SaaS; sus integraciones con LTI y APIs de terceros son puntos ciegos frecuentes.
    • Cláusulas de governance en contratos con proveedores: verificar que los contratos vigentes incluyan obligaciones de clasificación, notificación de incidentes y limitación de uso. En muchas organizaciones latinoamericanas, estas cláusulas no existen o son genéricas.

    El ángulo LATAM: brecha, notificación y responsabilidad distribuida

    Canvas tiene presencia activa en universidades de Brasil, México, Argentina y Colombia, entre otros países. Si el incidente involucró datos de estudiantes latinoamericanos —lo cual es altamente probable dado el alcance reportado— entran en juego marcos regulatorios concretos. En Brasil, la LGPD (Lei 13.709/2018) obliga al controlador a notificar a la ANPD dentro de un plazo razonable cuando la brecha pueda acarrear riesgo o daño relevante; Instructure, como operador, tiene responsabilidad solidaria si no implementó las medidas técnicas pactadas. En Argentina, la Ley 25.326 y la Disposición AAIP 4/2019 establecen la obligación de reportar incidentes de seguridad. En México, el INAI ha sido explícito en que los responsables no pueden delegar su obligación de custodia al subcontratar servicios. Ninguna de estas jurisdicciones acepta “fue el proveedor” como exoneración del responsable principal.

    El sector universitario latinoamericano, que adoptó Canvas masivamente durante la pandemia, hereda ahora un modelo de governance de datos construido sobre urgencia operativa, no sobre diseño. Los equipos de TI universitarios raramente cuentan con un CDO formal ni con un catálogo activo de datos sensibles. El CDMC (Cloud Data Management Capabilities) del EDM Council ofrece una referencia útil: las capacidades de gestión de riesgo de terceros corresponden al dominio 9 del framework, y la mayoría de las universidades de la región operaría en nivel 1 o por debajo si se midiera formalmente.

    La lección que no es nueva, pero sigue sin aprenderse

    Los incidentes por terceros no son accidentes de seguridad: son síntomas de ownership difuso. Cuando nadie en la organización puede responder en menos de 24 horas a “¿qué datos tiene acceso ese proveedor y quién autorizó eso?”, el data governance falló antes de que llegara el atacante. El caso de Instructure debería ser el disparador para que los responsables de datos en el sector educativo latinoamericano eleven este punto en la próxima reunión de rectorado o de directorio, no como un tema de IT, sino como un riesgo institucional con implicancias legales directas.

    El vector fue un proveedor, pero la vulnerabilidad era de gobierno: sin ownership claro del dato y sin lineage hacia afuera, cualquier integración de terceros es una puerta entreabierta.

  • Brecha en proveedor de salud de EE.UU. expone datos de 3,8 millones de pacientes

    Brecha en proveedor de salud de EE.UU. expone datos de 3,8 millones de pacientes

    Un incidente de seguridad en Unlimited Technology Systems, empresa de gestión de ciclo de ingresos para el sector salud con sede en Montgomery, Ohio, resultó en la exposición de datos de aproximadamente 3,8 millones de pacientes. La brecha se produjo entre el 10 y el 15 de octubre de 2025, fue detectada el 19 de octubre y recién trascendió públicamente con un reporte actualizado en julio de 2026, revelando una ventana de divulgación que supera los ocho meses desde el evento original.

    Qué se sabe del incidente

    Unlimited Technology Systems opera como proveedor de servicios de revenue cycle management (RCM) para organizaciones del sistema de salud estadounidense. Su función implica el procesamiento de información clínica y financiera de pacientes en nombre de múltiples entidades cubiertas bajo la norma HIPAA, lo que convierte a este tipo de proveedores en un vector de alto impacto cuando sufren compromisos: un solo incidente en el eslabón tercerizado puede propagar el daño a través de toda la cadena de clientes. Según se informó, los datos involucrados corresponden a registros de salud y, potencialmente, información de identificación personal de los pacientes afectados, aunque el detalle completo de los tipos de datos comprometidos no fue divulgado en la información disponible al cierre de esta nota.

    La demora entre la detección del incidente —octubre de 2025— y la divulgación pública amplia —julio de 2026— pone en el centro del debate la eficacia de los mecanismos de notificación obligatoria. Bajo HIPAA, las entidades cubiertas y sus business associates tienen plazos definidos para notificar a los afectados y al Departamento de Salud y Servicios Humanos de EE.UU. (HHS), pero la escala del impacto no siempre se conoce de forma inmediata, especialmente cuando el incidente involucra a un tercero que agrega datos de múltiples clientes.

    El riesgo del modelo RCM y la cadena de custodia de datos

    Los proveedores de RCM representan uno de los puntos de concentración más críticos en el ecosistema de datos de salud. Centralizan información de facturación, diagnósticos, números de seguro, datos demográficos y, en muchos casos, documentación clínica parcial. Esta arquitectura de agregación es funcional para la operación, pero multiplica el radio de impacto de cualquier compromiso. El caso de Unlimited Technology Systems no es aislado: el sector salud acumula consistentemente los costos por brecha más altos de cualquier industria, según el reporte anual de IBM Cost of a Data Breach, que en su edición 2024 ubicó el promedio en 9,77 millones de dólares por incidente en ese sector.

    Desde una perspectiva de data governance, el incidente expone fallas en al menos tres dimensiones: la clasificación y el control de acceso sobre datos sensibles de pacientes en entornos de terceros, la ausencia o insuficiencia de cláusulas contractuales de notificación ágil en los acuerdos con proveedores, y la falta de monitoreo continuo sobre el data lineage —es decir, el rastro de dónde están los datos, quién los procesa y bajo qué condiciones— cuando esos datos salen del perímetro de la organización de salud original.

    Implicancias para proveedores de servicios en LATAM

    El modelo de tercerización de procesos de datos en salud es una práctica creciente en América Latina. En Brasil, los operadores de planos de saúde que transfieren datos a proveedores de RCM o de gestión administrativa están sujetos a la Lei Geral de Proteção de Dados (LGPD), que en su artículo 42 establece responsabilidad solidaria entre controlador y operador cuando el daño deriva de un tratamiento en violación a la ley. La Autoridade Nacional de Proteção de Dados (ANPD) ha intensificado su actividad fiscalizadora desde 2024, y un incidente de esta magnitud protagonizado por un operador local difícilmente pasaría sin consecuencias formales. En Argentina, la Ley 25.326 y su decreto reglamentario obligan a los responsables de bases de datos a adoptar medidas técnicas y organizativas para garantizar la seguridad, con responsabilidad extensible a los cesionarios. En México, la LFPDPPP y los Lineamientos del INAI en materia de seguridad aplican criterios similares de responsabilidad sobre encargados del tratamiento.

    Lo que el caso de Ohio ilustra con claridad es que la debilidad regulatoria no es la causa raíz: HIPAA existe desde 1996 y tiene requisitos de seguridad administrativos, físicos y técnicos detallados. El problema es la ejecución del modelo de gestión de riesgos en terceros, un área donde incluso organizaciones con marcos maduros presentan brechas operativas significativas.

    Qué deberían revisar los equipos de datos este lunes

    Para los responsables de datos en organizaciones del sector salud o en proveedores que gestionan información sensible, este incidente ofrece un punto de entrada concreto para al menos tres revisiones inmediatas:

    • Inventario de proveedores con acceso a datos de pacientes o clientes: verificar si existen acuerdos de procesamiento de datos (DPA) vigentes, con cláusulas de notificación en plazos no mayores a 72 horas desde la detección, alineados con estándares como LGPD Art. 48 o GDPR Art. 33.
    • Revisión del data lineage sobre datos que salen del perímetro organizacional: ¿sabemos exactamente qué registros están en manos de qué tercero, bajo qué propósito y con qué controles de acceso? Si la respuesta no es inmediata, hay un gap de governance que documentar en el registro de riesgos.
    • Simulacro de notificación: ¿cuánto tardaría el equipo en identificar a los titulares afectados, cuantificar el alcance y activar el protocolo de comunicación? En el marco del CDMC (Cloud Data Management Capabilities) del EDM Council, la capability de Data Protection incluye explícitamente la capacidad de respuesta ante incidentes como un indicador de madurez.

    Cuando 3,8 millones de registros de pacientes quedan expuestos por un proveedor que nadie menciona en el titular, la pregunta que deberían hacerse los CDOs de la región no es “¿nos puede pasar esto?” sino “¿cuánto tardaríamos en saberlo?”.