Modelos transparentes y explicables

Un modelo rechaza una solicitud, y ocho meses después alguien pregunta por qué. Si esa pregunta llega y el equipo no tiene una frase que aguante ser leída en voz alta, el problema no fue la precisión del modelo sino la arquitectura que se eligió, los documentos que nunca se escribieron y la explicación que nadie diseñó para quien tenía que leerla. Este tema cubre la tarea 4.2 del examen completa: qué separa a un modelo legible de una caja negra, qué artefactos dejan rastro, y cómo hacer que una explicación le sirva a una persona real.

Qué cubre este tema

• la diferencia entre transparencia, explicabilidad e interpretabilidad, y cuáles de las tres son dimensiones de IA responsable de AWS
• cómo se lee una predicción dentro de un modelo interpretable, y por qué esa lectura desaparece en un ensemble grande o en un modelo fundacional
• explicación posterior con SHAP en SageMaker Clarify, partial dependence plots, y la diferencia entre explicaciones globales y locales
• por qué el baseline elegido cambia la explicación de la misma predicción, con baselines no informativos e informativos
• las dos concesiones que nombra el examen: interpretabilidad contra rendimiento, y transparencia contra seguridad
• SageMaker Model Cards para los modelos que construyes, con risk ratings, usos previstos y versionado inmutable
• AWS AI Service Cards para los modelos que consumes, leídas con la card de Amazon Nova Reel como caso real
• evaluaciones de Amazon Bedrock en sus formas programática, con modelo juez, humana y de RAG
• pesos abiertos, datos de entrenamiento abiertos y licencias como tres propiedades distintas, con el caso de SageMaker JumpStart
• diseño centrado en las personas: explicación según la audiencia, revelación del uso de IA, marca de agua y Content Credentials, retroalimentación que vuelve al entrenamiento y supervisión humana en decisiones consecuentes

Por qué es importante

Las preguntas de este tema suelen darte un escenario y cuatro artefactos plausibles. Un comité de riesgo que pregunta quién aprobó el modelo quiere una model card; un equipo que evalúa un servicio antes de construir quiere una AI Service Card; un cliente que pregunta por su propio caso quiere una explicación local de Clarify. Saber cuál entrega cada una es la mitad del dominio.

Fuera del examen, es lo que decide si tu sistema puede dar cuenta de sí mismo. Un modelo que nadie puede explicar funciona igual de bien hasta el día en que alguien con autoridad hace la pregunta, y ese día la respuesta ya está determinada por decisiones que tomaste mucho antes.