Tu Data Lake es un activo enorme para el negocio — y por eso mismo es un blanco enorme si no lo protegés bien. Esta es una charla teórica y conceptual: no vamos a hacer un demo paso a paso, sino construir un modelo mental sólido para que te lleves ideas claras de dónde y cómo empezar a implementar seguridad en tu propio Data Lake en AWS.

Vamos a recorrer la seguridad como un modelo de anillos concéntricos: desde el perímetro (quién puede entrar) hasta el dato mismo (quién puede verlo, y qué parte de él). Vemos quiénes son los actores típicos en un Data Lake (el Curator, el Miner, el Business User) y por qué cada uno necesita un nivel de acceso distinto — no todos necesitan ver todo. Entramos en la diferencia conceptual entre KMS y CloudHSM y cuándo conviene cada uno (spoiler: no siempre es "el más seguro"), y cerramos con la lógica detrás de un patrón de auditoría con CloudTrail + Athena, para que puedas responder la pregunta que todo compliance quiere saber: ¿quién tocó qué, y cuándo?

Hoy cada vez más Data Lakes terminan siendo la fuente de datos de agentes de IA — y ahí la seguridad deja de ser una buena práctica para convertirse en un requisito no negociable. Si un agente tiene acceso a datos mal ordenados, mal etiquetados o sin control de permisos claro, el riesgo ya no es solo un dato mal expuesto: es un agente actuando sobre información que nunca debió ver. Por eso insistimos tanto en que todo quede ordenado y preparado desde el diseño — para evitar sustos y problemas graves antes de que aparezcan.

Si laburás con datos en AWS y la seguridad todavía te parece "algo que configura otro equipo", esta charla te da el mapa para empezar a implementarla vos mismo.