AWS Certified AI Practitioner
Estrategias de gobernanza de datos para IA
Cómo gobernar los datos de un sistema de IA durante toda su vida: reglas de retención que de verdad borran, límites de residencia que sobreviven a la inferencia entre regiones, y el logging y monitoreo que vuelven demostrable la gobernanza.
- Distinguir gobernanza de datos y seguridad de datos, y nombrar la pregunta que responde cada una
- Mapear las etapas del ciclo de vida de los datos e identificar dónde la IA crea copias adicionales
- Configurar la retención de forma deliberada en S3, CloudWatch Logs y AWS CloudTrail
- Explicar cómo la inferencia entre regiones de Amazon Bedrock afecta la residencia de datos
- Comparar los registros de CloudTrail con el logging de invocaciones de modelos de Amazon Bedrock
- Describir las prácticas de monitoreo y observación que mantienen un sistema de IA dentro de su política
Un cliente le escribe a soporte y pide que borren sus datos. Sabes exactamente dónde están: la tabla customers en S3. Borras las filas y respondes el correo.
Seis semanas después, una revisión legal lista dónde estaban de verdad los datos de ese cliente el día de la solicitud. El export crudo en la zona de aterrizaje. La tabla curada que sí tocó el borrado. Los chunks de la knowledge base construidos con sus tickets de soporte, todavía en el vector store como embeddings. El log group de CloudWatch con cada prompt y cada respuesta del asistente, incluidas tres conversaciones donde un agente pegó el registro completo de la cuenta dentro del prompt. Un CSV que un data scientist bajó a un notebook en marzo. Y un modelo ajustado que leyó todo eso durante el entrenamiento.
Borraste una de seis copias y le dijiste al cliente que estaba listo.
Nada de esto fue una falla de seguridad. Cada bucket estaba cifrado, cada rol acotado, cada camino de red era privado. Lo que faltaba era la otra mitad: un conjunto de reglas que dijera cuánto tiempo puede existir cada copia, dónde tiene permitido vivir, para qué se puede usar y quién decide. Eso es gobernanza de datos, y la guía del examen la nombra con seis palabras: ciclos de vida, logging, residencia, monitoreo, observación y retención.
La gobernanza es el reglamento, la seguridad es la cerradura
Mantén estos dos separados, porque fallan distinto.
La seguridad pregunta: ¿puede alguien no autorizado llegar a estos datos? Responde con IAM, cifrado, aislamiento de red y detección de amenazas. El tema anterior fue casi todo seguridad.
La gobernanza pregunta: ¿bajo qué reglas viven estos datos, sin importar quién llegue a ellos? Cuánto los podemos guardar, qué países pueden procesarlos, para qué propósitos están aprobados, quién firma un uso nuevo, y cómo demostramos cualquiera de esas cosas después.
Un dataset perfectamente asegurado puede ser igual una falla de gobernanza. Nadie vulneró el log group de la historia de arriba. Estaba autorizado, cifrado y retenido para siempre porque nadie puso un número. La cerradura funcionaba; no había reglamento.
Esa distinción también explica por qué las preguntas de gobernanza suenan distinto a las de seguridad en el examen. Los enunciados de seguridad dicen "impedir el acceso". Los de gobernanza dicen "no se puede conservar más de", "tiene que permanecer dentro de", "hay que poder demostrar".
El ciclo de vida, y dónde la IA lo multiplica
Todo dataset pasa por las mismas etapas: se crea o se adquiere, se almacena, se usa, se archiva y al final se destruye. Las aplicaciones tradicionales mantienen ese camino angosto. Una base de datos, un respaldo, un archivo histórico.
Los sistemas de IA lo abren en abanico. Un solo ticket de soporte recorre esto:
- Aterriza como texto crudo en una landing zone de S3.
- Se redacta y se escribe en una tabla curada dentro de un segundo bucket.
- Se corta en chunks y se convierte en embeddings dentro de un vector store para recuperación.
- Entra en un corpus de fine-tuning, y su contenido influye en los pesos del modelo.
- Aparece en un prompt en tiempo de inferencia, y ese prompt y su respuesta caen en un log.
- Se toma para un set de evaluación en una revisión de calidad.
Seis ubicaciones a partir de un registro, con dueños distintos, servicios de almacenamiento distintos y vidas naturales distintas. La pregunta de gobernanza no es "¿tenemos política de retención?". Es "¿la política nombra las seis?".
Una de las seis es diferente al resto, y es la que se olvida. Los pasos 1 a 3, 5 y 6 guardan datos que puedes borrar. El paso 4 no: lo que un modelo aprendió durante el fine-tuning no se quita borrando un archivo. Por eso los controles previos a la ingesta del tema anterior también son controles de gobernanza. Todo lo que te niegas a entrenar es una copia que nunca vas a tener que rendir.
Retención: la configuración cuyo valor por defecto es "para siempre"
La retención es donde la política escrita se encuentra con un valor de configuración real, y los valores por defecto rara vez coinciden con lo que dice tu política.
| Almacén | Retención por defecto | Cómo la cambias |
|---|---|---|
| Objetos de Amazon S3 | Se conservan hasta que los borres | Regla de S3 Lifecycle con acciones de transición y expiración |
| Amazon CloudWatch Logs | Nunca expiran | Ajuste de retención en el log group |
| Event history de CloudTrail | 90 días de eventos de administración, fijos | No configurable; crea un trail o un event data store para más tiempo |
| Trail de CloudTrail hacia S3 | Se conservan hasta que los borres | Regla de S3 Lifecycle en el bucket destino |
| Event data store de CloudTrail Lake | Hasta unos 10 años, según la opción de precio elegida | Periodo de retención del event data store |
Lee de nuevo la fila de CloudWatch Logs. Por defecto, los datos de log se almacenan de forma indefinida. Para un log de aplicación común eso es un problema de costo. Para una aplicación de IA con logging de invocaciones habilitado, el log group contiene el cuerpo completo de peticiones y respuestas, así que es un almacén permanente de todo lo que los usuarios escribieron en el modelo y de todo lo que el modelo contestó. Hereda la sensibilidad de la conversación, no la de un log normal.
Un plan de retención trabajado para un asistente interno se ve así:
| Datos | Política | Mecanismo |
|---|---|---|
| Exports crudos de soporte | 90 días en la landing zone | Expiración de S3 Lifecycle a los 90 días |
| Corpus curado de entrenamiento | 3 años, inmutable | Bucket versionado, Object Lock, sin expiración por lifecycle |
| Chunks del vector store | Se reconstruyen cada semana desde la fuente curada | Job de reingesta, no una regla de retención |
| Logs de prompts y respuestas | 30 días | Retención de CloudWatch Logs en 30 días para ese log group |
| Actividad de API en CloudTrail | 7 años | Trail hacia S3, transición a Glacier a los 90 días, expiración a los 7 años |
| Sets de evaluación | 1 año después de retirar el modelo | Revisión manual, registrada en el catálogo de datos |
Fíjate que "borrar después de N días" y "guardar por N años" usan la misma herramienta desde extremos opuestos, y que dos de las seis filas no son una regla de lifecycle. La gobernanza no es una sola función.
Una corrección que conviene hacer explícita, porque es un supuesto común: bajar el periodo de retención no borra los datos al instante. CloudWatch marca los eventos vencidos para eliminación y normalmente completa el borrado dentro de las 72 horas. Si una política exige borrado demostrable para una fecha límite, contempla ese margen.
Residencia: dónde tienen permitido estar los datos
La residencia de datos es el requisito de que los datos se almacenen, y con frecuencia se procesen, dentro de una geografía nombrada. Aparece en banca, salud y sector público, y AWS la responde sobre todo con la elección de región: eliges la región y tus datos se quedan ahí salvo que los muevas.
La IA generativa agrega un detalle que al examen le gusta, porque es el único lugar donde un servicio de AWS puede procesar tu petición en una región que tú no nombraste.
La inferencia entre regiones de Amazon Bedrock rutea una petición hacia la región del conjunto que tenga capacidad, lo que sube el throughput y absorbe picos de tráfico. Hay dos tipos de profile, y solo uno respeta un límite de residencia:
| Inference profile geográfico | Inference profile global | |
|---|---|---|
| Dónde se pueden procesar las peticiones | Dentro de la geografía declarada, como US, EU o APAC | Cualquier región comercial de AWS admitida en el mundo |
| Throughput | Mayor que una sola región | El más alto disponible |
| Costo | Precio estándar | Alrededor de 10 por ciento menos |
| Encaja con | Requisitos de residencia de datos | Prioridad de costo y rendimiento sin restricción geográfica |
AWS deja la recomendación sin ambigüedad: elige geográfico cuando tengas requisitos de residencia de datos, y global cuando quieras el máximo throughput y ahorro sin restricciones geográficas.
Tres detalles mantienen esto honesto. La inferencia entre regiones puede rutear a regiones que no habilitaste manualmente en tu cuenta, así que "nunca prendimos esa región" no es un control. Todo el tráfico se queda en la red de AWS y va cifrado en tránsito, así que esto es una pregunta de jurisdicción y no de exposición. Y cada petición entre regiones queda registrada en CloudTrail en tu región de origen, con un campo additionalEventData.inferenceRegion que nombra dónde se procesó de verdad, que es como auditas la residencia después en vez de suponerla.
Si tu organización necesita el límite impuesto en vez de elegido, eso es una service control policy sobre aws:RequestedRegion a nivel de AWS Organizations, por encima de lo que configure cualquier equipo.
Logging: dos registros de una misma llamada
Para un servicio normal de AWS, "habilita el logging" significa una cosa. Para una llamada generativa significa dos, y cada una captura una mitad distinta.
| AWS CloudTrail | Logging de invocaciones de Bedrock | |
|---|---|---|
| Registra | La llamada a la API: quién, cuándo, qué acción, desde dónde | El contenido: cuerpo completo de petición y respuesta, model ID, conteo de tokens |
| Estado inicial | Encendido por defecto para eventos de administración en Event history | Apagado por defecto; lo habilitas por región |
| Destino | Event history, un trail hacia S3, o CloudTrail Lake | Amazon S3, CloudWatch Logs, o ambos |
| Responde | "¿Qué principal llamó a InvokeModel a las 02:14?" | "¿Qué decía ese prompt?" |
| Sensibilidad | Metadatos sobre actividad | Tan sensible como la conversación misma |
La consecuencia de gobernanza de esa última fila es la que hay que llevarse. Encender el logging de invocaciones es la decisión correcta para auditabilidad e investigación de incidentes, y crea un almacén nuevo de tu texto más sensible. Necesita el mismo trato que los datos de origen: una clave KMS, una política de acceso ajustada, un valor de retención y un lugar en tu mapa de borrado. Hay equipos que lo habilitan por cumplimiento y después reprueban otro control de cumplimiento con los logs que ellos mismos crearon.
Monitoreo y observación
La guía del examen lista monitoreo y observación como palabras separadas, y la división es útil aunque el borde sea difuso.
El monitoreo se basa en umbrales y es automático. Defines cómo se ve "mal" en forma de número, y algo avisa cuando pasa. Para una carga de IA: tasas de error y throttling de invocaciones en CloudWatch, cantidad de intervenciones de guardrails, costo por cada mil invocaciones, latencia en el percentil 99, y una regla de Config que se vuelve no conforme cuando alguien apaga el logging de invocaciones.
La observación es la mirada continua a lo que el sistema está haciendo de verdad, incluidas cosas para las que nunca escribiste un umbral. Deriva de datos y deriva de calidad del modelo con SageMaker Model Monitor, métricas de sesgo recalculadas sobre tráfico real con SageMaker Clarify, revisión humana de salidas por muestreo, y lectura periódica de los prompts que la gente realmente manda. La observación es cómo te enteras de que el asistente se está usando para algo que nadie diseñó, un hallazgo de gobernanza que ninguna alarma estaba configurada para atrapar.
Las dos importan, y la razón es propia de la IA: un sistema de IA no falla de forma limpia. Un servidor web mal configurado devuelve 500. Un modelo que se está degradando devuelve respuestas fluidas, bien formadas y plausibles que cada vez son peores. El monitoreo de disponibilidad no se va a dar cuenta.
La parte que no es un servicio
Dos elementos de gobernanza no tienen consola en AWS, y los dos van primero.
La clasificación pone cada dataset en un nivel (público, interno, confidencial, restringido, por ejemplo) y cuelga las reglas del nivel en vez de colgarlas de cada bucket. Requisitos de cifrado, regiones aprobadas, periodos de retención y si el nivel puede usarse para entrenar modelos dependen todos de esa sola etiqueta. Sin eso, cada dataset nuevo reabre la misma discusión.
La propiedad nombra a una persona responsable de cada dataset. El dueño de los datos clasifica, aprueba solicitudes de acceso y aprueba usos nuevos, incluido "¿podemos hacer fine-tuning con esto?". AWS te da las herramientas para registrar y aplicar esas decisiones, con etiquetas, el Glue Data Catalog y permisos de Lake Formation. No las puede tomar por ti.
El etiquetado es donde las dos se encuentran con la maquinaria. Una etiqueta consistente como DataClassification=Restricted en buckets, log groups y trabajos de entrenamiento es lo que le permite a una regla de Config revisar cumplimiento por nivel de política en vez de por nombre de recurso, y lo que deja desglosar reportes de costo y acceso por sensibilidad.
Consejos para el examen
- "Gobernanza de datos" en un enunciado apunta a reglas sobre los datos (retención, residencia, propósito, propiedad), no a control de accesos. Si el escenario dice "impedir acceso no autorizado", volviste a seguridad.
- La retención de CloudWatch Logs por defecto es "nunca expira". Ese solo dato responde varias formas de pregunta sobre logs que crecen sin fin o que guardan datos más allá de una fecha límite.
- El Event history de CloudTrail son 90 días de eventos de administración y no es configurable. Retención más larga significa un trail hacia S3 o un event data store de CloudTrail Lake.
- Las reglas de S3 Lifecycle son el mecanismo tanto para mover datos a almacenamiento más barato como para borrarlos en fecha.
- "Los datos tienen que quedarse en la UE" más Amazon Bedrock significa inference profile geográfico, no global.
- CloudTrail registra la llamada; el logging de invocaciones de Bedrock registra el contenido. Una pregunta sobre qué decía un prompt necesita el segundo, que viene apagado.
- Deriva, recálculo de sesgo y revisión humana por muestreo son observación. Alarmas y umbrales son monitoreo.
La regla que hay que llevarse: la gobernanza es el conjunto de decisiones que tienen que existir antes de que un control tenga algo que hacer cumplir. Periodos de retención, límites de residencia, clasificaciones y dueños son las entradas, y cada servicio de la última lección de este tema solo revisa si la realidad coincide con ellas. La próxima lección cubre de dónde salen esas decisiones, empezando por el marco que AWS nombra para acotar un caso de uso generativo.