En este episodio de Cloud para Todos veremos una constante batalla por mantenerse actualizado en el mundo del desarrollo de software y el cloud obviamente. La idea de este episodio surgió desde LinkedIn con una pregunta que leí: ¿Hay diferencia entre un modelo de Machine Learning (ML) y un modelo de IA como un LLM? En este capítulo revelamos una distinción crucial entre procesos predictivos y generativos que muchas organizaciones están pasando por alto al integrar la IA en sus proyectos.Estando desde hace muchos años acompañando a Devs enfocado en el Software Development Life Cycle (SDLC) (y ahora metido de lleno con la IA), he podido notar que siempre tenemos una batalla que pelear. Y la batalla de hoy me suena muy parecida a una que ya peleamos.... ¿Te acuerdas cuando empezó a globalizarse el uso de las herramientas cloud? Todos los Devs venían: Héctor…. ¿Cómo hago para tener un usuario? Dame una cuenta para probar mis cosas…. Darle acceso permanente no era la mejor idea. Las instancias quedaban prendidas sin control, bases de datos levantadas sin ningun dueño (si nadie se hacia cargo), y pasaba una factura de 200 dólares a 1000 dólares en una noche.Bueno, hoy está pasando lo mismo. Pero en lugar de credenciales cloud, los compañeros de equipo preguntan: ¿Qué API Key podemos utilizar para probar con IA? Entonces viene la gran pregunta, ¿nos pasamos a credenciales de proveedoreso usamos servicios ya existentes? Al estilo de OpenAI, Anthropic, etc. O nos quedamos con AWS Bedrock? Debemos de pensar en el modelo de precios, gobierno, etc.Y acá es donde debemos de reaccionar... Antes de empezar: ¿qué necesitas y qué vas a lograr? Pre-requisitos: No necesitas ser un experto en IA ni en Machine Learning. Lo que sí necesitas es tener lo básico de tu cuenta de AWS en orden. * AWS Organizations configurado con al menos una OU para tus cuentas de desarrollo * IAM Identity Center (SSO) habilitado, los devs ya deben poder hacer `aws sso login` * Permission Sets creados por equipo (ej: BackendDev, FrontendDev, QATeam) * Amazon Bedrock habilitado en eu-west-1 (o la región que aplique según tu rgulación) * AWS CDK o Terraform para desplegar la infraestructura como código * Conocimientos básicos de IAM Policies, SCPs y CloudWatch: Si ya gestionas cuentas cloud con SSO y policies, ya tienes todo lo que necesitas. ¿Qué vas a lograr al final? Cuando termines de implementar lo que te voy a mostrar, vas a tener:Acceso gobernado a LLMs por equipo, Guardrails automáticos, Restricción geográfica, Presupuesto por equipo con corte automático, Dashboard de consumo, Auditoría completa, Reset mensual automático. Y lo más importante: el developer puede empezar a usar IA desde el día 0 con sus credenciales AWS SSO de siempre, sin esperar a que alguien le consiga una API Key ni pagar nada de su bolsillo. El problema real: herramientas sin gobierno = caos Seamos sinceros. No muchas organizaciones tienen reglamentadas estas herramientas. Tenemos a gente copiando y pegando código de clientes en modelos, sin saber las implicaciones que tiene. Cada quien utiliza el IDE (que muchas veces paga de su bolsillo), la que tiene a la mano, o la que puede acceder de forma gratuita.Ahí hay que tener bastante cuidado.Ahora, la idea no es controlar. La idea es monitorear y darles herramientas a todos los compañeros para que puedan utilizar la IA de forma segura. Se trata de dar opciones para que puedan sacar el mayor provecho, no de limitar. ¿Y cómo logramos eso desde el día 1? Resulta que si ya trabajas con AWS, las herramientas ya las tienes. No necesitas desplegar un proxy (por ahora), no necesitas infraestructura adicional. Solo necesitas policies. El déjà vu: lo que aprendimos del mundo cloud aplica con IA también Pensemos un momento en cómo resolvimos el acceso cloud. No le dimos a cada dev una AccessKey permanente con permisos de administrador. Aprendimos (a las malas, muchos de nosotros) que lo correcto era:1. Identity Center (SSO): credenciales temporales, no permanentes2. IAM Policies: permisos específicos por rol o equipo3. SCPs: límites a nivel organizacional que nadie puede saltarse4. AWS Budgets: alertas cuando el gasto se dispara¿Seguro te suena todo esto no? Porque la estrategia para gobernar el acceso a LLMs es exactamente la misma (casi ya veremos). Gobierno Cloud vs Gobierno IA Generativa ☁️ Cloud (lo que ya hacemos) 🤖 IA Generativa (lo que necesitamos) IAM User con access keys Credenciales SSO temporales Permisos granulares por servicio Permisos granulares por modeloSCPs para limitar regiones SCPs para limitar regiones + modelosAWS Budgets para alertar CloudWatch + Lambda para cortar antes del desastreCloudTrail para auditoría CloudTrail + métricas de tokens La diferencia es la velocidad. En cloud, un error de costos se nota en días. En IA, un bucle de razonamiento puede gastar 50 dólares en 5 minutos. Por eso necesitamos un mecanismo de corte activo, no solo alertas. SPOILER: AWS Budgets no sirve para esto. Ya que tiene una latencia de hasta 24 horas para cortar el acceso, en términos de IA es una eternidad. Diagrama de lo que estamos creando: El dev no necesita aprender nada nuevo. Ya sabe hacer aws sso login. Lo único que cambia es que invoca el modelo a través de un Inference Profile de su equipo en lugar del model ID directo. ¿Qué necesitamos configurar? La IAM Policy del equipo Esta policy dice: solo puedes usar los modelos de tu equipo, y siempre con AWS Bedrock Guardrail. { "Version": "2012-10-17", "Statement": [ { "Sid": "AllowInvokeViaTeamProfile", "Effect": "Allow", "Action": ["bedrock:Converse", "bedrock:ConverseStream"], "Resource": [ "arn:aws:bedrock:eu-west-1:123456789012:inference-profile/team-*" ] }, { "Sid": "DenyWithoutGuardrail", "Effect": "Deny", "Action": ["bedrock:Converse", "bedrock:ConverseStream"], "Resource": "*", "Condition": { "StringNotEquals": { "bedrock:GuardrailIdentifier": "arn:aws:bedrock:eu-west-1:123456789012:guardrail/corp-guard-001/version/1" } } } ] } ¿Qué pasa si el dev intenta invocar un modelo que no está en su lista? AccessDeniedException. ¿Sin guardrail? AccessDeniedException. No hay forma de saltárselo. El Guardrail que protege todo Los Guardrails de Bedrock actúan como un firewall semántico. Si el Desarrollador sin querer pega un correo electrónico, numero de documento, un número de tarjeta o hasta una AWS_SECRET_KEY en el prompt, el guardrail lo intercepta antes de que llegue al modelo. # CDK simplificado bedrock.CfnGuardrail(self, "CorpGuardrail", name="corp-ai-guardrail", sensitive_information_policy_config={ "piiEntitiesConfig": [ {"type": "EMAIL", "action": "ANONYMIZE"}, {"type": "PHONE", "action": "ANONYMIZE"}, {"type": "CREDIT_DEBIT_CARD_NUMBER", "action": "BLOCK"}, {"type": "AWS_ACCESS_KEY", "action": "BLOCK"}, {"type": "AWS_SECRET_KEY", "action": "BLOCK"}, ] } ) El mecanismo de corte: presupuesto en tokens, no en dólares Algo que debes de saber: AWS Budgets tiene un retraso de 24 horas para reflejar costos. Si un dev entra en un bucle que quema tokens sin parar, la alerta llega al día siguiente. Para IA generativa, eso es poco real. La solución que vamos a estar haciendo: un Accumulator mediante una simple Lambda que cada 5 minutos suma los tokens consumidos por el equipo (de todos sus Inference Profiles) y publica una custom metric. Una alarma de CloudWatch monitorea esa métrica y dispara el corte. Código (resumido) # Lambda: Accumulator (se ejecuta cada 5 min) def handler(event, context): for team_name, profile_arns in TEAM_PROFILES.items(): total_tokens = 0 for profile_arn in profile_arns: for metric in ["InputTokenCount", "OutputTokenCount"]: response = cloudwatch.get_metric_statistics( Namespace="AWS/Bedrock", MetricName=metric, Dimensions=[{"Name": "InferenceProfileArn", "Value": profile_arn}], StartTime=month_start, EndTime=now, Period=86400 * 31, Statistics=["Sum"], ) for dp in response["Datapoints"]: total_tokens += int(dp["Sum"]) # Publicar acumulado MTD como custom metric cloudwatch.put_metric_data( Namespace="Custom/BedrockGovernance", MetricData=[{ "MetricName": "TokensMTD", "Dimensions": [{"Name": "Team", "Value": team_name}], "Value": total_tokens, "Unit": "Count", }], ) ¿Y que va pasar cuando esta alarma se active? Tendremos otra Lambda que le inyectará al profile del equipo que corresponda una política para bloquear cualquier acceso a LLMs. # Budget Cut Lambda, tarda en hacer efecto en ~10-30 segundos, mucho más rapido que las 24hs de AWS Budgets def _cut_access(team_name, role_name): iam.put_role_policy( RoleName=role_name, PolicyName="BudgetExceeded-AutoDeny-Bedrock", PolicyDocument=json.dumps({ "Version": "2012-10-17", "Statement": [{ "Effect": "Deny", "Action": ["bedrock:Converse", "bedrock:ConverseStream"], "Resource": "*", }] }), ) Limitaciones, mejoras: * El día 1 de cada mes, lo ideal es que un EventBridge scheduled rule remueve la Deny policy y el equipo arranca de nuevo. * Si tienes alguna fo
