AWS es donde llegamos cuando el cliente ya tiene gobernanza, compras y revisión de seguridad maduras alrededor de esa nube. No siempre es el lugar más simple para empezar un producto de IA, pero muchas veces es donde producción tiene que vivir.
La razón para elegir AWS no es que IA sea más fácil ahí. La razón es que el cliente ya sabe operar AWS: cuentas, IAM, VPCs, logs, incident response, procurement y excepciones de seguridad ya tienen dueño.
Dónde encaja AWS
- Equipos enterprise que ya operan IAM, VPCs, logging e incident response en AWS.
- Flujos de IA con datos privados, jobs en cola y límites claros de ownership.
- Productos donde compras valora más el control operativo que el prototipo más rápido.
- Sistemas agenticos que necesitan tool calls detrás de colas, rutas privadas de datos, credenciales acotadas y límites claros de blast radius.
Qué miramos de cerca
- Sprawl de IAM. La forma más rápida de volver irrevisable un sistema de IA es dejar que cada worker, retriever y ruta de exportación crezca sus propios permisos.
- Costo oculto de orquestación. Los tokens no suelen ser la única factura. Colas, object storage, logs, egress, embeddings y retries necesitan presupuesto propio.
- Gaps de observabilidad. Trazas de LLM, retrieval y aplicación tienen que volver a la misma acción de usuario o el runbook falla en el primer incidente.
Decisiones que solemos tomar
- Mantener credenciales y datos del cliente bajo la cuenta del cliente desde el día uno.
- Poner ingestión, extracción y exportación detrás de colas explícitas en vez de requests largos.
- Separar model routing de la lógica de producto para que gane un modelo más barato cuando pasa la evaluación.
- Tratar los artefactos de seguridad como entregables de producto, no papeleo de última semana.
Qué incluimos en el handover
- Mapa de IAM para rutas de modelo, retrievers, workers, exports y operadores humanos.
- Política de colas y retries para tareas largas de ingestión, extracción y agentes.
- Dashboard de costo separando tokens, embeddings, logs, colas, storage y egress.
- Runbook para caída de proveedor, pico de costo, miss de retrieval, tool call mal formado y rollback.
- Notas de revisión de seguridad que explican flujo de datos, ownership de credenciales y audit logs.
Cuándo lo evitamos
Si el equipo no opera AWS todavía y el proyecto no necesita gobernanza específica de AWS, empezar ahí puede frenar el build sin mejorar el producto. No elegimos AWS porque suena enterprise. Lo elegimos cuando el modelo operativo ya vive ahí.
Trabajo relacionado
BidGenie es el patrón público más cercano: ingestión de documentos, drafting grounded en retrieval, revisión humana, exportación y despliegue sobre proveedores auditados.