F5 - 5.0 MARCO CONCEPTUAL: POR QUÉ EL SECTOR DEFINE LOS REQUISITOS

§5.0 Marco Conceptual — El triángulo Regulatorio-Ético-Operacional y por qué la dimensión regulatoria es siempre prioritaria.

§5.1 Financiero/Bancario — Análisis profundo de SR 11-7, DORA (enero 2025) y EU AI Act. Tabla de 10 criterios de evaluación (obligatorio/alto/diferencial) + scorecard de 8 proveedores con notas específicas (EchoLeak en Azure, lobbying OpenAI, ventaja XAI de Google, IBM como líder de sector).

§5.2 Salud/Ciencias de la Vida — HIPAA/BAA como filtro binario, FDA SaMD y el problema de modelos con actualizaciones automáticas. Tabla de 7 criterios + mapa de 7 proveedores (IBM y AWS lideran en control de versiones; OpenAI y Anthropic con gaps en SaMD).

§5.3 Gobierno/Defensa — FedRAMP como filtro primario (Azure/Google/AWS tienen High; Anthropic/OpenAI solo via cloud partners). Soberanía de datos LATAM y evaluación de ownership extranjero (xAI/SpaceX, Alibaba).

§5.4 Legal/Servicios Profesionales — Attorney-client privilege, deber de confidencialidad, riesgo de alucinaciones en citas jurídicas (post-Mata v. Avianca) y opiniones de los colegios de abogados de NY y California.

§5.5 Preguntas Críticas — 8 preguntas universales + batería sectorial, con referencia regulatoria específica para cada una.

§5.6 Scorecard Maestro — Matriz 8 proveedores × 4 sectores con calificación ★★★/★★☆/★☆☆/✕ e IBM como único proveedor con ★★★ en todos los sectores.

§5.7 Red Flags — 8 señales de alerta con proveedores afectados identificados (xAI investigaciones, debilitamiento RSP, clausulado ambiguo, cambio de control SpaceX).

5.0 MARCO CONCEPTUAL: POR QUÉ EL SECTOR DEFINE LOS REQUISITOS

Las fases 1 a 4 de este análisis construyeron una visión horizontal de los 16 proveedores: sus filosofías de alignment, metodologías de seguridad, mecanismos de transparencia y exposición a dilemas éticos. La Fase 5 adopta la perspectiva inversa: parte del sector del comprador y determina qué criterios de evaluación son obligatorios, cuáles son diferenciales, y cuáles son secundarios, en función de las obligaciones regulatorias específicas de cada industria.

Esta perspectiva es crítica porque la relevancia de cada hallazgo de las fases anteriores varía dramáticamente según el contexto de uso. Un gap en las políticas de privacidad de un proveedor puede ser tolerable para un equipo de marketing en retail, pero constituye un bloqueante absoluto para un hospital bajo HIPAA. La misma solución técnica, ante el mismo proveedor, puede ser apropiada o inapropiada dependiendo del uso.

5.0.1 El Triángulo Regulatorio-Ético-Operacional

La evaluación de proveedores de IA en industrias reguladas requiere navegar simultáneamente tres dimensiones que frecuentemente entran en tensión:

DIMENSIÓN REGULATORIA	DIMENSIÓN ÉTICA	DIMENSIÓN OPERACIONAL
Cumplimiento de normas específicas del sector (SR 11-7, HIPAA, DORA, EU AI Act). Requisito no negociable. Incumplimiento genera liability directa.	Alineación con los hallazgos de las Fases 1-4: sesgo, privacidad, transparencia, seguridad agéntica. Requisito que protege reputación y mitiga riesgos futuros.	Capacidad real de integración, disponibilidad, soporte, coste total y velocidad de adopción. Requisito que determina viabilidad práctica del proyecto.

⚠ Advertencia de priorización: En industrias reguladas, la dimensión regulatoria es siempre prioritaria: un proveedor que no cumple con SR 11-7 en banca, o que no puede firmar BAA bajo HIPAA en salud, está descalificado independientemente de sus méritos éticos o técnicos. Este documento organiza la evaluación respetando este principio.

5.0.2 Estructura de la Evaluación Sectorial

Para cada sector, esta fase documenta: (A) el marco regulatorio aplicable y sus implicaciones para la selección de proveedores de IA; (B) los criterios de evaluación obligatorios (compliance gates), diferenciales y secundarios; (C) el mapeo de los 16 proveedores analizados contra esos criterios; y (D) las preguntas específicas que el equipo de due diligence debe formular a cada proveedor.

Los sectores cubiertos son los de mayor concentración de requisitos regulatorios y mayor exposición en las fases anteriores de este análisis: Financiero/Bancario, Salud/Ciencias de la Vida, Gobierno/Defensa y Legal/Servicios Profesionales. Otros sectores como Retail, Manufactura o Educación pueden derivar su framework de la combinación de elementos de estos cuatro.

5.1 SECTOR FINANCIERO Y BANCARIO

📋 Marco regulatorio primario: SR 11-7 (Fed/OCC/FDIC, 2011 — vigente), DORA (EU, entrada en vigor enero 2025), EU AI Act Artículo 6/Anexo III (sistemas alto riesgo, phased-in hasta agosto 2026), OCC/FDIC/Fed TPRM Guidance (2023), FINRA (mercados), ECOA/Fair Lending (crédito), AML/CFT frameworks.

5.1.1 SR 11-7: El Marco Fundacional para Modelos de IA en Banca

La Supervisory Guidance SR 11-7 (Federal Reserve/OCC, abril 2011, adoptada por FDIC en 2017) fue diseñada para modelos cuantitativos de riesgo crediticio, pero la posición regulatoria consolidada en 2024-2025 es clara: sus principios se aplican a sistemas de IA/ML que informen decisiones con consecuencias materiales. El OCC confirmó en su Fall Risk Perspective 2024 que los LLMs utilizados en funciones de decisión bancaria deben ser tratados bajo el framework MRM.

Tres pilares de SR 11-7 aplicados a IA: (1) Desarrollo conceptualmente sólido —documentación completa de supuestos, limitaciones y condiciones de uso apropiado—; (2) Validación independiente —evaluación objetiva por personal sin conflicto de interés en el resultado del modelo—; (3) Gobernanza robusta —inventario de modelos, supervisión del board, políticas de uso y monitoreo continuo de drift—.

La aplicación de SR 11-7 a proveedores terceros de IA introduce una complicación estructural: las instituciones bancarias son responsables de validar modelos que los proveedores consideran propietarios y no auditable por terceros. La Guidance TPRM 2023 (OCC/Fed/FDIC) establece que esto no exime a la institución de la obligación de validación: si el proveedor no permite acceso suficiente para validación independiente, la institución debe evaluar si puede asumir responsablemente ese riesgo de modelo.

5.1.2 DORA: Resiliencia Operacional Digital para el Sector Financiero Europeo

El Digital Operational Resilience Act (Reglamento UE 2022/2554) entró en vigor el 17 de enero de 2025 para todas las entidades financieras que operan en la UE. Su relevancia para la selección de proveedores de IA es directa: DORA exige que los contratos con proveedores TIC críticos —categoría en la que puede caer un proveedor de IA que soporte funciones críticas o importantes— incluyan cláusulas específicas de auditoría, subcontratación, portabilidad de datos, planes de salida y SLAs mínimos.

La orientación de BaFin de diciembre 2025 clarificó adicionalmente que la IA se clasifica como riesgo TIC bajo DORA y debe ser integrada en el framework ICT risk management de la institución. Esto implica que los sistemas de IA de terceros requieren los mismos controles de identificación, protección, detección, respuesta y recuperación que cualquier otro sistema TIC crítico.

Para entidades con operaciones en América Latina con exposición regulatoria europea (e.g., filiales de grupos bancarios europeos, entidades que acceden a mercados de capitales europeos), DORA establece estándares contractuales mínimos que superen lo que la mayoría de los proveedores de IA ofrecen en sus términos estándar.

5.1.3 EU AI Act y el Sector Financiero

El EU AI Act (junio 2024) clasifica como sistemas de alto riesgo los sistemas de IA utilizados para: evaluación de solvencia crediticia, scoring de riesgo, detección de fraude con impacto en personas naturales, y decisiones sobre acceso a servicios financieros esenciales (Anexo III, punto 5.b). Para estas aplicaciones, la fecha de compliance es el 2 de agosto de 2026 (potencialmente extendida hasta diciembre 2027 bajo la propuesta Digital Omnibus de noviembre 2025).

Los requisitos del EU AI Act para sistemas alto riesgo que impactan la selección de proveedor incluyen: documentación técnica exhaustiva del sistema, registro en base de datos EU, evaluación de conformidad, gestión de riesgos a lo largo del ciclo de vida, datos de entrenamiento representativos y sin sesgos relevantes, logging automático, transparencia hacia usuarios, supervisión humana efectiva, y exactitud/robustez/ciberseguridad documentadas.

5.1.4 Criterios de Evaluación: Sector Financiero

CRITERIO	DESCRIPCIÓN Y EVIDENCIA REQUERIDA	PRIORIDAD
Documentación de modelo (Model Card)	Ficha técnica completa: arquitectura, datos de entrenamiento (proveniencia, características), limitaciones conocidas, condiciones de uso apropiado. Requerido por SR 11-7 §IV.B para modelos en producción.	OBLIGATORIO
Acceso para validación independiente	El proveedor debe facilitar suficiente acceso técnico para que el validador independiente interno o externo de la institución pueda evaluar conceptual soundness. Si el modelo es caja negra, el proveedor debe proveer resultados de sus propias validaciones con metodología documentada.	OBLIGATORIO
Cláusulas DORA en contrato	Para entidades UE o filiales de grupos UE: derecho de auditoría, requisitos de subcontratación (4th party risk), SLAs mínimos, plan de salida documentado, portabilidad de datos. Verificar si el proveedor tiene clausulado estándar compatible con DORA o requiere negociación.	OBLIGATORIO (UE)
Explicabilidad de decisiones (XAI)	Para modelos que informen decisiones de crédito, detección de fraude o scoring: capacidad de generar explicaciones específicas por caso (reason codes) conformes a ECOA Regulation B y FCRA. SHAP/LIME outputs documentados. EU AI Act requiere explicabilidad para sistemas alto riesgo.	OBLIGATORIO (crédito/fraude)
Testing de sesgo / fairness	Evidencia documentada de testing de disparate impact analysis por clases protegidas (raza, sexo, edad, origen nacional). Metodología de la regla del 80%. Frecuencia de re-testing ante cambios de modelo. Crítico post-Mobley v. Workday (mayo 2025).	OBLIGATORIO
Monitoreo continuo y alertas de drift	Sistema de monitoreo en producción que detecte model drift, data drift y performance degradation. SLAs de alerta y procedimientos de respuesta documentados. SR 11-7 §IV.C.	ALTO
Zero Data Retention / No Training	Garantía contractual de que los datos de clientes no se usan para entrenar el modelo base. Preferiblemente ZDR (no persistencia en logs). Crítico para datos de clientes bancarios bajo GDPR/CCPA.	ALTO
Certificaciones de compliance	SOC 2 Type II (seguridad, disponibilidad, confidencialidad), ISO 27001. HIPAA BAA no requerida en banca salvo datos de salud. FedRAMP si hay operaciones gubernamentales.	ALTO
Gestión de incidentes y notificación	Procedimientos de incident response con SLAs de notificación alineados a DORA (máx. 4 horas para incidentes mayor) y regulaciones locales aplicables. Historial de incidentes previos y forma de gestión.	DIFERENCIAL
Inventario de subproveedores (4th party)	Lista de proveedores TIC críticos del proveedor de IA (infraestructura cloud, modelos base, APIs de terceros). Evaluación de concentración de riesgo. Requerido por DORA para proveedores críticos.	DIFERENCIAL

5.1.5 Mapa de Proveedores: Sector Financiero

La siguiente tabla sintetiza la adecuación de los proveedores evaluados en Fases 1-4 a los requisitos del sector financiero, cruzando los hallazgos de ética/riesgo con los criterios regulatorios específicos.

PROVEEDOR	SR 11-7Doc.	XAI /Fairness	DORACompatible	ZDREnterprise	NOTAS CLAVE
Microsoft Azure OpenAI	ALTO	MEDIO	ALTO	SÍ	Azure cumple DORA como ICT provider reconocido. EchoLeak CVE-2025-32711 requiere controles adicionales en Copilot. Model cards parciales.
OpenAI Enterprise	MEDIO	MEDIO	PARCIAL	SÍ	Indemnización IP enterprise sin cap. Clausulado DORA requiere negociación. Lobbying contra regulación estatal IA es señal de alerta para evaluadores de riesgo regulatorio.
Google Vertex AI	ALTO	ALTO	ALTO	SÍ	EU Data Boundary, FedRAMP High, SynthID. Indemnización training + outputs. Mejor ecosistema XAI del sector (What-If Tool, Explainable AI). Jailbreaks Gemini 3 requieren monitoreo adicional.
AWS Bedrock	MEDIO	MEDIO	ALTO	SÍ	No entrena con datos cliente (contractual). Indemnización solo modelos propios (Titan). Hereda certificaciones AWS. Flexibilidad multi-modelo es ventaja operacional para validación independiente.
Anthropic Enterprise	MEDIO	BAJO	PARCIAL	SÍ	Settlement Bartz $1.5B requiere atención legal. Fortaleza en safety/alignment. ZDR disponible. Escasa herramienta XAI para explicabilidad de decisiones específicas. Concord Music activo.
IBM Watsonx	ALTO	ALTO	ALTO	SÍ	Mejor posicionamiento sector financiero regulado. AI FactSheets (doc. modelo), AI Fairness 360 toolkit, OpenScale (monitoreo). Datos entrenamiento Granite documentados. Indemnización Granite/Slate.
Meta AI (Llama 4)	BAJO	BAJO	NO	N/A*	*Open weights: no hay relación contractual. Institución asume toda la responsabilidad de validación, fairness testing, y cumplimiento regulatorio. Válido únicamente para despliegue auto-hospedado con equipo MRM interno maduro.
Databricks	ALTO	ALTO	ALTO	SÍ	DAGF (Databricks AI Governance Framework) diseñado para sectores regulados. MLflow para trazabilidad de modelos. Unity Catalog para linaje de datos. No es lab de modelos base: la institución entrena sobre sus propios datos.

5.2 SECTOR SALUD Y CIENCIAS DE LA VIDA

📋 Marco regulatorio primario: HIPAA (EEUU) + BAA requirements, FDA SaMD (Software as a Medical Device) — 21 CFR Part 820, EU AI Act categorías alto riesgo (Anexo III punto 5 y 6 — dispositivos médicos), GDPR para datos de salud (categoría especial Art. 9), CCPA, leyes de privacidad de salud estatales (CMIA California), y normas de interoperabilidad HL7/FHIR.

5.2.1 HIPAA y la Obligación de Business Associate Agreement (BAA)

La Health Insurance Portability and Accountability Act establece el requisito más binario de toda la evaluación de proveedores en salud: si el proveedor procesa, almacena o transmite Protected Health Information (PHI) —incluyendo como parte de prompts o contexto de modelos de IA— debe poder firmar un Business Associate Agreement (BAA). Un proveedor que no pueda o no quiera firmar BAA está automáticamente descalificado para cualquier caso de uso que involucre PHI.

El mercado de proveedores de IA frontier muestra una segmentación clara respecto a este requisito: Microsoft Azure OpenAI, Google Cloud Healthcare AI, AWS Bedrock, IBM Watsonx y la API de Anthropic en modalidad enterprise ofrecen BAA para casos de uso elegibles. OpenAI lanzó ChatGPT for Healthcare en 2025 con BAA disponible. En contraste, los planes consumer (ChatGPT Plus, Claude.ai personal, Gemini Advanced personal) no califican para BAA y no pueden procesar PHI.

5.2.2 FDA SaMD y Sistemas de IA para Decisiones Clínicas

Cuando la IA no es solo una herramienta de productividad clínica sino que influye directamente en decisiones diagnósticas o terapéuticas, puede caer bajo la jurisdicción de la FDA como Software as a Medical Device (SaMD). El framework FDA IAFP (Predetermined Change Control Plan) establece que los cambios en el modelo subyacente que puedan afectar el rendimiento clínico requieren notificación o autorización previa.

Esta realidad tiene implicaciones directas para la selección de proveedor: los modelos hosted por el proveedor que se actualizan automáticamente (como GPT-4o, Claude, Gemini) crean riesgo de compliance bajo SaMD porque el proveedor puede actualizar el modelo sin que la institución pueda controlar o documentar el cambio. Los modelos open source auto-hospedados o los modelos fine-tuned con versiones congeladas ofrecen mayor control regulatorio para aplicaciones SaMD.

5.2.3 Criterios de Evaluación: Sector Salud

CRITERIO	DESCRIPCIÓN Y EVIDENCIA REQUERIDA	PRIORIDAD
Firma de BAA (Business Associate Agreement)	Requisito absoluto para cualquier procesamiento de PHI. Verificar que el BAA cubra el servicio específico (algunos proveedores tienen BAA para la API pero no para el playground/interfaz web). Revisar definición de PHI en el BAA del proveedor.	OBLIGATORIO
Zero Data Retention y no uso para entrenamiento	PHI nunca debe usarse para entrenar modelos base del proveedor. ZDR (zero data retention) garantiza que los prompts con PHI no son almacenados. Verificar que el ZDR aplique también a logs de seguridad y abuse monitoring.	OBLIGATORIO
Residencia y soberanía de datos	PHI debe procesarse en la región geográfica acordada. Para entidades europeas: datos de salud son 'datos especiales' bajo GDPR Art. 9 con restricciones adicionales. Verificar que el proveedor ofrezca processing en región específica y no traslada datos entre regiones sin consentimiento.	OBLIGATORIO
Control de versiones del modelo (congelamiento)	Para aplicaciones SaMD o decisiones clínicas: capacidad de fijar una versión específica del modelo y ser notificado/autorizar antes de cualquier actualización que pueda afectar rendimiento clínico. Los modelos con actualización automática sin control son problemáticos bajo FDA SaMD.	OBLIGATORIO (SaMD)
Auditoría y trazabilidad de decisiones	Logs completos de inputs y outputs para revisión posterior en caso de adverse event o reclamación. Retención de logs conforme a regulaciones de historiales médicos (mínimo 6-7 años en EEUU). Compatible con requisitos de documentación clínica.	ALTO
Privacidad by design para datos de salud	Anonimización, pseudonimización o tokenización de PHI antes de enviar a modelo. Minimización de datos en prompts. El proveedor debe proveer guidance técnico sobre cómo estructurar casos de uso sin exponer PHI innecesaria.	ALTO
Testing de sesgo en poblaciones clínicas	Evidencia de evaluación de rendimiento diferencial por demografías médicamente relevantes (edad, sexo, raza/etnicidad). Crítico para aplicaciones diagnósticas donde el sesgo documentado en entrenamiento puede resultar en outcomes clínicos dispares.	ALTO
Interoperabilidad HL7/FHIR	Capacidad de integrarse con sistemas EMR/EHR existentes mediante estándares de interoperabilidad. Relevante para casos de uso de extracción de datos clínicos, resumen de registros, o apoyo a decisión clínica integrado en flujo de trabajo.	DIFERENCIAL

5.2.4 Mapa de Proveedores: Sector Salud

PROVEEDOR	BAADisponible	ZDRPHI	SaMDControl	NOTAS CLAVE
Microsoft Azure OpenAI	SÍ	SÍ	MEDIO	Azure Healthcare AI + BAA estándar. Hereda certificaciones Azure HIPAA. Copilot para clínicas disponible. Versiones de modelo controlables en Azure OpenAI Service (deployment propio). EchoLeak CVE-2025-32711 requiere mitigación en entornos clínicos.
OpenAI (ChatGPT for Healthcare)	SÍ	SÍ	BAJO	BAA lanzado 2025 para ChatGPT for Healthcare. Sin control de versión de modelo para clientes estándar (GPT-4o se actualiza automáticamente). Riesgo SaMD significativo. Proceso MDL NYT revela 20M conversaciones almacenadas — impacto en confianza PHI.
Google Cloud Healthcare AI	SÍ	SÍ	MEDIO	Healthcare Data Engine, MedPaLM 2, Cloud Healthcare API. BAA robusto. EU Data Boundary para GDPR. FedRAMP High. Mejor suite de herramientas clínicas específicas del mercado. Gemini no disponible con garantías SaMD en versión estándar.
AWS Bedrock + HealthLake	SÍ	SÍ	ALTO	AWS HealthLake + Bedrock integrado. BAA heredado de AWS. Amazon Comprehend Medical para NLP clínico. Mayor control sobre versiones de modelos (Claude, Llama disponibles con versiones pinned). Compliance HIPAA/GxP documentado.
Anthropic Enterprise	SÍ	SÍ	BAJO	BAA disponible vía API enterprise. ZDR disponible. Sin herramientas clínicas específicas. Actualizaciones de modelo no siempre permiten versiones congeladas. Concord Music activo no es relevante para salud. Opción preferida como reasoning engine embebido en plataforma clínica propia.
IBM Watsonx Health	SÍ	SÍ	ALTO	Oferta específica para salud (Watsonx Health). BAA estándar. Modelos Granite con datos documentados. Control total de versiones en despliegues privados. FactSheets para trazabilidad de modelos clínicos. Mejor posicionamiento compliance SaMD del mercado.
Meta Llama 4 (self-hosted)	N/A	N/A	ALTO*	*Solo si es auto-hospedado con infraestructura propia certificada HIPAA. La institución asume responsabilidad total de compliance. Máximo control de versiones y datos. Requiere capacidad de ML/MLOps interna significativa. No apto para instituciones sin equipo técnico especializado.

5.3 SECTOR GOBIERNO Y DEFENSA

📋 Marco regulatorio primario: FedRAMP (EEUU — Federal Risk and Authorization Management Program), CMMC (Cybersecurity Maturity Model Certification, DoD), ITAR (International Traffic in Arms Regulations), EAR (Export Administration Regulations), FISMA, Executive Orders sobre seguridad nacional e IA (EO 14110 y revisiones 2025), CISA AI Security Guidelines, NATO STANAG/AI Policy 2024, regulaciones locales de soberanía digital (Latinoamérica: Brasil LGPD + soberanía datos, Argentina Ley 25.326, regulaciones sectoriales).

5.3.1 FedRAMP: El Filtro Primario para Proveedores Gubernamentales EEUU

Federal Risk and Authorization Management Program establece el estándar de seguridad mínimo para proveedores de servicios en la nube que operan con agencias federales de EEUU. El proceso de autorización FedRAMP puede demorar 12-18 meses y requiere una inversión sustancial del proveedor. El status FedRAMP de un proveedor es por tanto una señal tanto de capacidad técnica como de compromiso con el sector gubernamental.

Status FedRAMP por proveedor (febrero 2026): Microsoft Azure: FedRAMP High (GovCloud). Google Cloud: FedRAMP High (gobierno). AWS GovCloud: FedRAMP High. IBM Cloud: FedRAMP Moderate/High. Anthropic: No tiene FedRAMP propio (accesible vía AWS Bedrock GovCloud o Azure Government que sí lo tienen). OpenAI: No tiene FedRAMP propio (accesible vía Azure Government). Meta Llama: open weights, no aplica como servicio SaaS.

5.3.2 Consideraciones de Soberanía de Datos para Gobierno Latinoamericano

Para organismos gubernamentales en América Latina —incluyendo entidades como el gobierno argentino, brasileño o mexicano, o empresas de defensa nacionales— los requisitos de soberanía digital están emergiendo como factor determinante. Argentina está desarrollando una infraestructura de nube gubernamental soberana (ONTI), Brasil ha establecido restricciones en la LGPD y en la Política Nacional de Segurança da Informação sobre dónde pueden residir datos gubernamentales sensibles.

La ubicación de los centros de datos de los proveedores de IA y las restricciones de transferencia internacional de datos son factores críticos para agencias gubernamentales que manejan información clasificada o sensible. Los proveedores con infraestructura en regiones de América Latina (AWS São Paulo, Google Cloud São Paulo/Santiago/Buenos Aires, Azure Brasil Sur) tienen ventaja regulatoria para clientes gubernamentales de la región.

5.3.3 Criterios de Evaluación: Sector Gobierno y Defensa

CRITERIO	DESCRIPCIÓN Y EVIDENCIA REQUERIDA	PRIORIDAD
FedRAMP Authorization (EEUU)	Para agencias federales EEUU: autorización FedRAMP Moderate mínima, High para sistemas con datos sensibles. Verificar que el servicio específico de IA (no solo la plataforma cloud) esté en el scope de la autorización. Muchos proveedores tienen FedRAMP para infraestructura pero no para sus modelos de IA específicos.	OBLIGATORIO (EEUU)
Soberanía y residencia de datos nacional	Para gobiernos LATAM: confirmación contractual de que los datos procesados no salen del territorio nacional o de la región autorizada. Mapeo de centros de datos disponibles en la región. Ausencia de transferencias a EEUU (datos sujetos a CLOUD Act) para datos soberanos sensibles.	OBLIGATORIO
Restricciones de propiedad y control extranjero	ITAR/EAR para defensa EEUU. Para gobiernos LATAM: evaluación del ownership real del proveedor (inversión china en proveedores cloud, conexiones con gobiernos extranjeros). xAI/Grok y adquisición SpaceX (feb. 2026) requieren evaluación de riesgo geopolítico adicional. Alibaba/Tencent/Huawei: inaceptables para datos de defensa en aliados EEUU.	OBLIGATORIO (defensa)
Clasificación de información y segregación	Sistemas de IA para uso gubernamental deben soportar etiquetado y segregación de información por nivel de clasificación. Entornos aislados (air-gapped) para información clasificada. Auditoría de accesos por personal del proveedor a instancias gubernamentales.	ALTO
Investigación de antecedentes del personal proveedor	Política del proveedor sobre background checks para personal con acceso a infraestructura que aloja datos gubernamentales. Restricciones de ciudadanía para personal con acceso a sistemas clasificados. Relevante en contexto de supply chain attacks (Salt Typhoon documentado en Fase 4).	ALTO
Transparencia de modelo y auditoría gubernamental	Derecho de auditoría técnica del gobierno sobre el sistema de IA. Acceso a documentación de model card, datos de entrenamiento, evaluaciones de seguridad. Capacidad de inspección por ente regulador sin depender de self-reporting del proveedor.	ALTO
Planes de continuidad y estrategia de salida	Riesgo de concentración: dependencia de un único proveedor para funciones gubernamentales críticas. Plan documentado de salida (data portability, migración). Garantías de continuidad en caso de insolvencia del proveedor o cambio de política (ej. cambio de control corporativo).	DIFERENCIAL

5.4 SECTOR LEGAL Y SERVICIOS PROFESIONALES

📋 Marco regulatorio primario: Privilegio abogado-cliente (attorney-client privilege / secreto profesional), deber de confidencialidad de colegios de abogados, regulaciones locales de ejercicio profesional con IA (NY State Bar 2024, California Bar 2024, ABA Model Rules), e-discovery requirements (FRCP), Directivas de protección de datos aplicables al ejercicio profesional (GDPR para despachos europeos), normas de competencia diligente con uso de IA.

5.4.1 El Privilegio Abogado-Cliente en el Contexto de IA

El riesgo más crítico y específico del sector legal al usar proveedores de IA third-party es la potencial ruptura del privilegio abogado-cliente (attorney-client privilege) o del secreto profesional. Cuando información privilegiada es transmitida a un proveedor de IA cuyo modelo puede usar esa información para entrenar —o cuyos empleados pueden acceder técnicamente a ella— existe riesgo de waiver del privilegio, con consecuencias devastadoras para los clientes del despacho.

La posición de los colegios de abogados en 2024-2025 es consistente: los abogados tienen el deber de competencia diligente al seleccionar herramientas de IA, que incluye evaluar cómo el proveedor maneja los datos transmitidos. New York State Bar (2024) y California Bar (2024) publicaron opiniones éticas estableciendo que el uso de herramientas de IA sin evaluar el manejo de datos confidenciales puede constituir violación del deber de confidencialidad.

5.4.2 Hallucinations y Deber de Diligencia

El sector legal enfrenta un segundo riesgo específico: las alucinaciones de modelos LLM en citas jurídicas y referencias a precedentes inexistentes. Múltiples casos documentados en 2023-2025 (Mata v. Avianca, y casos análogos) resultaron en sanciones a abogados por presentar citaciones ficticias generadas por IA. Las reglas de competencia profesional imponen un deber de supervisión humana sobre outputs de IA antes de cualquier uso en documentos o presentaciones judiciales.

5.4.3 Criterios de Evaluación: Sector Legal

CRITERIO	DESCRIPCIÓN Y EVIDENCIA REQUERIDA	PRIORIDAD
Garantía de no uso para entrenamiento (datos privilegiados)	Confirmación contractual explícita de que comunicaciones privilegiadas transmitidas como input NO son usadas para entrenar el modelo base. ZDR preferible. DPA que incluya cláusula específica de no uso para model improvement. Sin esta garantía, el uso de IA con datos privilegiados es éticamente cuestionable.	OBLIGATORIO
Confidencialidad del proveedor (no acceso de empleados)	Política documentada sobre acceso de empleados del proveedor a contenido de los inputs/outputs. Para datos altamente sensibles: garantía de procesamiento sin acceso humano (automated systems only). Evidencia de controles técnicos que impiden acceso no autorizado.	OBLIGATORIO
Precisión en citas y referencias legales	Evaluación de hallucination rate en tareas jurídicas específicas (citas de casos, referencias a estatutos). Benchmarks independientes de precisión jurídica. Sistemas de grounding/RAG sobre bases de datos jurídicas verificadas (Westlaw, LexisNexis) que reduzcan alucinaciones. Claridad del proveedor sobre limitaciones.	OBLIGATORIO
Compatibilidad con e-discovery	Para despachos con práctica de litigación: capacidad de producción de documentos de forma que preserve metadata y sea defensible ante requerimientos de e-discovery bajo FRCP. Los sistemas de IA que procesan documentación legal deben preservar trazabilidad.	ALTO
Aislamiento de datos por cliente (multi-tenant)	Garantía de que datos de un cliente del despacho no pueden contaminar o ser accedidos en el contexto de queries relacionadas con otros clientes. Arquitectura de aislamiento documentada. Crítico para despachos con clientes en partes contrarias.	ALTO
Jurisdicción y ley aplicable al contrato	El contrato con el proveedor de IA debe estar bajo una jurisdicción predecible y compatible con las obligaciones profesionales del despacho. Cláusulas de arbitraje que puedan limitar el acceso a recursos judiciales para incumplimientos de confidencialidad deben evaluarse cuidadosamente.	DIFERENCIAL

5.5 PREGUNTAS CRÍTICAS DE DUE DILIGENCE POR SECTOR

La siguiente tabla consolida las preguntas que el equipo de due diligence debe formular directamente al proveedor (y cuyas respuestas deben obtenerse por escrito, incorporándose al expediente de evaluación). Las preguntas están organizadas por sector, pero muchas aplican transversalmente.

5.5.1 Preguntas Universales (Todos los Sectores)

#	PREGUNTA AL PROVEEDOR	POR QUÉ ES CRÍTICA
U-1	¿Pueden proveernos un Model Card o ficha técnica completa del modelo que usaríamos, incluyendo datos de entrenamiento, limitaciones conocidas y condiciones de uso apropiado?	Requerido por SR 11-7 en banca, EU AI Act para alto riesgo. Base de la validación independiente.
U-2	¿Nuestros datos (inputs y outputs) son usados para entrenar o mejorar sus modelos? ¿En qué circunstancias? ¿Cómo podemos verificar esto?	Crítico para todos los sectores regulados. Respuesta evasiva o condicionada es red flag.
U-3	¿Ofrecen Zero Data Retention para nuestra cuenta? ¿Qué procesos y logs quedan excluidos del ZDR?	Muchos ZDR tienen carve-outs para abuse monitoring que pueden no ser aceptables en sectores con datos altamente sensibles.
U-4	¿Tienen reportes de red team / evaluaciones de seguridad independientes que puedan compartir bajo NDA? ¿Con qué frecuencia se realizan?	Documenta robustez real del sistema. Ausencia total de evaluaciones independientes es señal de alerta.
U-5	¿Cuál es el proceso de notificación a clientes en caso de brecha de seguridad? ¿Cuál es el SLA de notificación?	Requerido por GDPR (72h), DORA (4h para incidentes mayores), regulaciones sectoriales.
U-6	¿Cuál es el status actual de todos los procedimientos legales relacionados con derechos de autor o uso de datos de entrenamiento que involucren a su compañía? ¿Cómo afecta esto potencialmente a nuestro uso?	Exposición litigiosa (Bartz, NYT, Concord Music etc.) puede crear contingencias contables o interrupciones operacionales.
U-7	¿Cuál es su política de fin de vida de modelos y cuánto tiempo de preaviso dan antes de deprecar un modelo que usamos en producción?	Cambios sin preaviso pueden interrumpir sistemas críticos. Evaluar con Anthropic post-depreciación acelerada Claude 3.x en 2025.
U-8	¿Qué controles tienen para prevenir prompt injection y ataques agénticos documentados en OWASP GenAI Top 10 (dic. 2025)?	Crítico para despliegues agénticos. EchoLeak CVE-2025-32711 demostró impacto real en entornos productivos.

5.5.2 Preguntas Específicas por Sector

SECTOR	PREGUNTAS ESPECÍFICAS	REFERENCIA REGULATORIA
FINANCIERO	¿Pueden proveernos documentación de validación independiente del modelo con metodología conforme a SR 11-7? ¿El modelo está en su inventario de modelos de riesgo? ¿Qué métricas de fairness han sido evaluadas y con qué frecuencia? ¿Pueden generar reason codes por decisión para cumplimiento ECOA? ¿Sus términos incluyen clausulado compatible con DORA para contratos con entidades UE?	SR 11-7 §IV, DORA Art. 30 (cláusulas contractuales), ECOA Regulation B, EU AI Act Art. 13 (transparencia)
SALUD	¿Pueden firmar un Business Associate Agreement (BAA) para nuestro caso de uso específico? ¿El BAA cubre procesamiento en la región donde residen nuestros datos? ¿Ofrecen versiones congeladas del modelo para aplicaciones SaMD? ¿Cómo garantizan que PHI transmitida en prompts no es almacenada ni usada para entrenamiento?	HIPAA §164.308, FDA IAFP, EU AI Act Anexo III §5-6, GDPR Art. 9
GOBIERNO	¿Cuál es el status de su autorización FedRAMP para el servicio específico que usaríamos? ¿En qué regiones geográficas pueden garantizar que residirán y se procesarán los datos? ¿Tienen restricciones de ciudadanía para personal con acceso a infraestructura que aloja datos gubernamentales? ¿Cuál es la estructura de propiedad accionaria final (beneficial ownership) de su compañía?	FedRAMP Rev. 5, CMMC 2.0, ITAR §120.10, soberanía digital regional
LEGAL	¿Pueden proveer garantía contractual explícita de que comunicaciones abogado-cliente transmitidas como input no serán usadas para entrenamiento ni accedidas por empleados del proveedor? ¿Cuál es el hallucination rate documentado para tareas de búsqueda y cita jurídica? ¿La arquitectura del sistema garantiza aislamiento total entre datos de distintos clientes del despacho?	ABA Model Rules 1.1 (competencia), 1.6 (confidencialidad), NY State Bar Op. 2024, California Bar Formal Op. 2024

5.6 SCORECARD DE SELECCIÓN DE PROVEEDOR POR SECTOR

El siguiente scorecard sintetiza la adecuación de los ocho proveedores con mayor presencia enterprise para cada sector regulado analizado. La calificación integra los hallazgos de las Fases 1-4 (ética, transparencia, seguridad) con los requisitos regulatorios sectoriales de esta Fase 5.

📌 Leyenda: ★★★ = Adecuado sin restricciones significativas | ★★☆ = Adecuado con precauciones / gaps menores | ★☆☆ = Adecuado solo con negociación contractual o controles adicionales | ✕ = No recomendado / bloqueante identificado

PROVEEDOR	SECTORFINANCIERO	SECTORSALUD	SECTORGOBIERNO	SECTORLEGAL
Microsoft Azure OpenAI	★★☆EchoLeak requiere mitigación	★★★BAA + ZDR sólidos	★★★FedRAMP High disponible	★★☆Controles datos privilegiados OK
OpenAI Enterprise	★★☆Lobbying regulatorio = señal alerta	★★☆ChatGPT Healthcare sin control versión	★☆☆No FedRAMP propio	★☆☆Alucin. citas documentadas
Google Vertex AI	★★★Mejor XAI + DORA-compatible	★★★Healthcare AI + EU Data Boundary	★★★FedRAMP High + data residency	★★☆Confidencialidad sólida
AWS Bedrock	★★☆Indemniz. solo Titan	★★★HealthLake + BAA + control versión	★★★GovCloud FedRAMP High	★★☆ZDR disponible
Anthropic Enterprise	★★☆Bartz settlement activo	★★☆BAA sí, control versión débil	★☆☆Sin FedRAMP propio	★★☆ZDR + no training OK
IBM Watsonx	★★★Mejor compliance regulado	★★★Watsonx Health específico	★★★FedRAMP + control total	★★★Mejor aislamiento datos
Meta Llama (self-hosted)	★☆☆Solo con MRM interno maduro	★☆☆Solo con infra HIPAA propia	★★☆Control total si self-hosted	★★☆Control total si self-hosted
Databricks	★★★Mejor plataforma gobernanza	★★★Control versiones + linaje datos	★★☆No FedRAMP propio; datos en cloud	★★★Aislamiento por workspace

5.7 RED FLAGS: SEÑALES DE ALERTA EN LA EVALUACIÓN DE PROVEEDORES

Independientemente del sector, las siguientes señales de alerta deben activar una revisión más profunda o reconsideración del proveedor durante el proceso de due diligence:

SEÑAL DE ALERTA	IMPLICACIÓN Y EVIDENCIA	PROVEEDORES AFECTADOS
🔴 Negativa a responder preguntas de due diligence por escrito	Proveedor solo provee respuestas verbales o redirige a documentación genérica. Imposibilita evidenciar el proceso de evaluación frente a reguladores. Riesgo de representaciones inexactas.	Varios (documentado con múltiples labs en investigación TechCrunch 2024)
🔴 Cláusulas de entrenamiento ambiguas en ToS	Redacción que permite 'mejorar el servicio' sin definir qué incluye esa mejora. Puede ser interpretada para incluir uso de datos del cliente en entrenamiento. Verificar cada versión del ToS vigente al momento del contrato.	Múltiples; evaluar caso a caso
🔴 Ausencia de system cards o red team reports	Sin system card no hay documentación pública de limitaciones conocidas. Sin red team reports no hay evidencia de evaluación de safety pre-lanzamiento. Ambos son señal de inmadurez en procesos de gobernanza de IA.	xAI/Grok (documentado FLI), GPT-4.1 (sin system card — documentado)
🔴 Litigación activa de copyright con exposición significativa	Riesgo de settlement que impacte en continuidad del servicio, cambios de política de entrenamiento, o costos que se trasladen a clientes. Evaluar por separado el riesgo de input (training) vs output (indemnización).	Anthropic (Bartz $1.5B + Concord Music), OpenAI (MDL NYT/Authors), Google (múltiples)
🔴 Investigaciones regulatorias activas	Investigaciones por privacidad (CNIL, Garante), sesgo (EEOC), derechos digitales (múltiples jurisdicciones) o seguridad (CISA) pueden resultar en sanciones, cambios operacionales forzados o restricciones al servicio.	xAI (5 jurisdicciones investigaciones activas)
🔴 Debilitamiento documentado de políticas de safety previo al lanzamiento	Patrón observado donde el proveedor publica un RSP o safety framework y luego lo debilita antes del lanzamiento de un nuevo modelo. Indica cultura de safety como marketing, no como práctica operacional.	Múltiples (documentado FLI AI Safety Index Winter 2025)
🔴 Cambio de control corporativo inminente o reciente	M&A, spin-offs o cambios de control pueden alterar políticas de privacidad, seguridad y cumplimiento. Los compromisos contractuales pre-adquisición pueden no ser vinculantes para el nuevo propietario.	xAI/SpaceX (feb. 2026), evaluar cualquier consolidación
🟡 Falta de presencia en la región para soporte y cumplimiento local	Proveedores sin entidad legal local pueden tener dificultades para firmar ciertos tipos de contratos, cumplir con regulaciones de soberanía de datos o responder requerimientos regulatorios locales.	Relevante para LATAM; múltiples proveedores sin entidad en Argentina/LATAM

5.8 REFERENCIAS

Marcos Regulatorios:

1. Federal Reserve / OCC, Supervisory Guidance SR 11-7 on Model Risk Management, abril 2011 (FDIC adoptó 2017). https://www.federalreserve.gov/supervisionreg/srletters/sr1107.htm

2. OCC/Fed/FDIC, Interagency Guidance on Third-Party Relationships: Risk Management (TPRM Guidance), 2023.

3. Reglamento UE 2022/2554 — Digital Operational Resilience Act (DORA). Entrada en vigor enero 2025.

4. Reglamento UE 2024/1689 — EU AI Act. K&L Gates, EU and Luxembourg Update on AI Act, enero 2026.

5. BaFin, Orientación sobre riesgos TIC con IA bajo DORA, diciembre 2025. Analizada en Banking Vision, febrero 2026.

6. OCC/Fed/FDIC, Consumer Bankers Association comment on OSTP AI RFI, octubre 2025.

7. Bank Policy Institute, Navigating Artificial Intelligence in Banking, abril 2024.

8. FINRA, 2025 Annual Regulatory Oversight Report: Third-Party Risk, enero 2025.

9. NCUA, Artificial Intelligence resources for credit unions, diciembre 2025.

10. FDA, Artificial Intelligence/Machine Learning-Based Software as a Medical Device (SaMD) Action Plan, 2021.

11. HHS/OCR, HIPAA BAA Requirements. https://www.hhs.gov/hipaa/for-professionals/business-associates/

Ética y Gobernanza de IA:

1. Future of Life Institute, AI Safety Index Winter 2025. Evaluación de 16 proveedores en múltiples dimensiones.

2. OWASP GenAI Security Project, OWASP Top 10 for Agentic Applications, diciembre 2025. genai.owasp.org

3. Apollo Research / OpenAI, Scheming evaluations o3 model, 2025.

4. Ramkumar Bharathan, Securing the Future of AI: SOC 2, ISO 27001 and NIST Comparative Review (Claude, Gemini, OpenAI), Technical Disclosure Commons, abril 2025.

Litigación y Régimen Contractual:

1. Ropes & Gray LLP, End-of-Year Update on AI-Related Copyright Litigation, diciembre 2024.

2. Ropes & Gray LLP, Anthropic's Landmark Copyright Settlement: Implications for AI Developers and Enterprise Users, septiembre 2025.

3. TechCrunch, AI vendors promised indemnification against lawsuits. The details are messy, enero 2024.

4. Microsoft, Copilot Copyright Commitment announcement (Brad Smith), septiembre 2023. blogs.microsoft.com

5. OpenAI, Services Agreement (public). https://openai.com/policies/services-agreement/

6. OpenAI, Service Terms (specific indemnification language). https://openai.com/policies/service-terms/

7. Google, Indemnification for Workspace and Cloud AI customers, diciembre 2023.

8. Wilson Sonsini, Will Indemnification Commitments Address Market Demands in AI?, 2024.

Ética Profesional y Sectores:

1. New York State Bar Association, Ethics Opinion on Use of Generative AI Tools, 2024.

2. California State Bar, Formal Opinion on Attorneys' Ethical Duties Regarding AI, 2024.

3. ABA Model Rules of Professional Conduct, Rules 1.1 (Competence) y 1.6 (Confidentiality), con comentarios sobre tecnología (2012, actualizados).

4. GRF CPAs & Advisors, Is Your Vendor's AI Putting You at Risk?, junio 2025.

5. Liminal AI, Enterprise AI Governance: Complete Implementation Guide, 2025.

6. Reruption, A Strategic Framework for Vendor Due Diligence in the Age of AI, enero 2026.