Las claves de AWS Bedrock ahora están protegidas por un gateway de LLM interno que permite a cada equipo de una empresa fintech llamar a los modelos, aunque cada solicitud está vinculada a un presupuesto de tokens por equipo. Este cambio pone fin a la práctica de dispersar credenciales de IAM por repositorios y notebooks, un hábito que ya amenazaba con agotar el gasto en IA de la empresa en una sola tarde.

Por qué repartir claves de AWS se convierte rápidamente en un caos

Los grupos no técnicos de la organización solicitaron acceso directo a los modelos de lenguaje de la empresa. Sobre el papel, la respuesta más sencilla era habilitar los modelos en AWS y otorgar un permiso de IAM a cada grupo. Diez minutos de trabajo, algunas ediciones de políticas y el trabajo estaba hecho; al menos en teoría.

En la práctica, repartir credenciales de IAM genera tres costes ocultos:

  • Dispersión de credenciales – Las claves terminan en archivos .env, pipelines de CI, notebooks de Jupyter y scripts ad-hoc. Cada copia se convierte en un punto de fallo cuando se requiere una rotación.
  • Visibilidad nula – Una única clave compartida no da ninguna pista sobre qué equipo o qué fragmento de código está generando el uso. Cuando se inicia un bucle descontrolado, todo el presupuesto puede consumirse antes de que alguien se dé cuenta.
  • Sobrecarga operativa – El seguimiento de quién tiene qué permiso, la revocación de accesos y la auditoría del uso se convierten rápidamente en un proceso manual y propenso a errores.

El equipo de la fintech se dio cuenta de que la "solución rápida" pronto se convertiría en una pesadilla de seguridad y costes.

En su lugar, construir un gateway de proxy inverso

La solución fue insertar un proxy inverso ligero entre cada aplicación interna y AWS Bedrock. El proxy mantiene las credenciales reales de AWS en una única ubicación protegida por un vault y emite tokens de corta duración y legibles para humanos (por ejemplo, lllkey_9f3c) a los clientes.

Puntos clave del diseño:

  • Ninguna credencial de AWS sale del gateway – Los desarrolladores y los servicios nunca ven las claves IAM reales.
  • Aplicación de políticas por token – Cada token puede limitarse a una familia de modelos específica o a un recuento máximo de tokens.
  • Pista de auditoría completa – Cada solicitud se registra con un nombre.

Cómo procesa una solicitud el gateway

  1. Recibir el token – El cliente incluye su token llmkey_… en el encabezado HTTP.
  2. Validar el token – El gateway comprueba el estado del token (activo, no expirado) y si la solicitud se mantiene dentro del presupuesto asignado.
  3. Lista blanca de modelos – Confirma que el modelo solicitado está permitido para ese token.
  4. Reenviar a Bedrock – La solicitud se envía a AWS utilizando las credenciales IAM almacenadas.
  5. Registrar y facturar – El uso del token, el nombre del modelo y la estimación de costes se escriben en una base de datos central para la elaboración de informes.

Debido a que la empresa fintech debe mantener todos los datos dentro de su propia red, una oferta SaaS de terceros quedaba descartada.

Lo que la empresa ganó

  • Control de modelos – Los equipos que solo necesitan un modelo de bajo coste pueden verse restringidos a él, evitando el uso accidental de variantes más caras y de mayor capacidad.
  • Protección del presupuesto – Los tokens tienen un límite estricto de tokens. Cuando se alcanza el límite, el gateway devuelve un error en lugar de consumir más créditos silenciosamente.
  • Atribución para finanzas – Un dashboard basado en los registros de uso muestra exactamente qué equipo o servicio gastó cuánto en IA, convirtiendo una hoja de cálculo vaga en un informe transparente.

El flujo de trabajo operativo también cambió. Sin nuevas políticas de IAM, sin rotación de secretos y sin riesgo de que las claves se filtren al control de versiones.

Contraargumento: ¿por qué no usar un servicio gestionado?

Una objeción común es que construir un gateway personalizado añade esfuerzo de ingeniería y mantenimiento. En el caso de la fintech, la necesidad de mantener todo el tráfico de IA y los datos de uso detrás del firewall corporativo superaba la conveniencia de una solución de terceros. El proxy interno requirió un fin de semana de desarrollo, pero eliminó meses de limpieza de credenciales y sobrecostes presupuestarios que habrían sido consecuencia del enfoque ingenuo de distribución de claves.

Conclusión

Repartir claves de AWS Bedrock es un atajo que rápidamente se convierte en una pesadilla de seguridad y presupuesto. Un modesto gateway de proxy inverso —construido en un fin de semana— centraliza las credenciales, aplica límites por equipo y proporciona la pista de auditoría que finanzas necesita. Para cualquier organización que quiera permitir que múltiples grupos experimenten con LLMs sin perder el control, el enfoque de gateway se amortiza solo mediante la prevención de incidentes y una mayor visibilidad del gasto.