Amazon Bedrock gestiona modelos, no la responsabilidad del cliente

Amazon presentó Bedrock el 13 de abril de 2023 como un servicio gestionado para acceder por API a modelos fundacionales de Amazon y de varias empresas. La promesa eliminaba una carga importante: operar la infraestructura. No eliminaba la obligación de demostrar que la aplicación construida encima era adecuada para su tarea, sus datos y las personas afectadas.

Esa diferencia es la capacidad duradera. «Gestionado» describe quién mantiene servidores y una parte de la plataforma; no transfiere automáticamente calidad, seguridad, cumplimiento ni responsabilidad. Antes de elegir una API de IA conviene redactar seis contratos internos: identidad del modelo, datos, adaptación, evaluación, operación y salida.

Lo que ofrecía la vista previa

El anuncio de AWS situó Bedrock en vista previa limitada y enumeró modelos de AI21 Labs, Anthropic, Stability AI y Amazon. La familia Titan empezaría con un modelo generativo para texto y otro de embeddings, representaciones numéricas útiles para búsqueda y personalización.

La plataforma sería serverless: el cliente consumiría los modelos sin administrar la infraestructura subyacente. AWS también describió personalización con ejemplos etiquetados almacenados en S3 y afirmó que los datos del cliente no alimentarían los modelos base. Eran características declaradas para una vista previa, no una disponibilidad uniforme para cualquier cuenta o región.

El anuncio de AI21 Labs del mismo día explicaba el beneficio desde el proveedor: Jurassic-2 podría consumirse dentro del entorno de AWS sin que el desarrollador gestionara infraestructura. Citaba tareas como resumen, redacción y preguntas sobre una base de conocimiento, además de varios idiomas.

Una lista de tareas no es una garantía para un caso concreto. «Resume» puede significar conservar cada obligación de un contrato o condensar una nota informal; «responde» puede exigir citas verificables o solo una conversación fluida. La compra comienza al convertir el verbo comercial en una prueba con criterios de error.

Contrato uno: identidad y versión

Una API estable puede ocultar modelos que cambian. El registro debe guardar proveedor, nombre exacto, versión, fecha, región, parámetros de generación y plantilla completa de instrucciones. Si una actualización mejora estilo pero cambia clasificación, el equipo necesita atribuir el resultado a una versión y volver atrás.

«Elección de modelos» solo existe cuando son comparables bajo el mismo conjunto de tareas. Cada candidato recibe las mismas entradas permitidas y se mide en calidad, latencia, coste, rechazos, variabilidad y seguridad. Un promedio global puede ocultar que un modelo falla justo en el idioma o documento que sostiene el negocio.

La aplicación tampoco debería asumir que todos comparten funciones. Longitud de contexto, formatos, embeddings, moderación y opciones de adaptación pueden variar. Una capa propia normaliza lo común y declara las dependencias específicas; fingir una interfaz universal produce fallos silenciosos.

Contrato dos: el recorrido de los datos

Se dibuja el trayecto de una petición: origen, aplicación, registros, API, proveedor del modelo, respuesta y almacenamiento posterior. En cada salto se anota qué campos viajan, propósito, cifrado, región, retención, acceso y borrado. El diagrama incluye metadatos, copias de depuración y resultados, no solo el texto del usuario.

La afirmación de AWS sobre el aislamiento de datos era relevante, pero una arquitectura completa añade el comportamiento del cliente. Si la propia aplicación guarda prompts en un registro abierto o incorpora secretos innecesarios, que el modelo base no entrene con ellos no evita la exposición.

El modelo de responsabilidad compartida de AWS distinguía seguridad de la nube, operada por el proveedor, y seguridad en la nube, que depende de servicio, configuración, datos e integración del cliente. Para IA se amplía la tabla: AWS, creador del modelo, desarrollador de la aplicación, organización usuaria y persona supervisora.

El reparto se prueba con escenarios, no con una casilla genérica. Si aparece un dato personal en la entrada, el cliente decide si debía recopilarse y enviarse; la plataforma debe aplicar sus controles; el proveedor del modelo debe cumplir el tratamiento acordado. Si la respuesta causa una decisión incorrecta, la organización usuaria conserva la obligación de revisión y recurso.

Para cada riesgo se nombra un propietario, un control, una evidencia y una respuesta. «El proveedor se ocupa» no vale si el contrato solo cubre infraestructura. «Lo revisa una persona» tampoco vale sin indicar qué ve, cuánto tiempo dispone, qué puede bloquear y cómo registra el desacuerdo. La matriz evita que la comodidad del servicio cree una zona sin dueño.

Contrato tres: qué significa personalizar

La noticia hablaba de ajustar una copia privada con ejemplos. Antes de hacerlo se define el objetivo: estilo, clasificación, extracción o conocimiento. Enseñar ejemplos de tono no convierte al modelo en una base de datos actualizada; aportar documentos no garantiza que toda respuesta quede respaldada por ellos.

Los datos de adaptación necesitan procedencia, permiso, calidad y una fecha de corte. Se separan entrenamiento y evaluación para no medir con los mismos ejemplos que enseñaron la tarea. También se conserva el modelo base como referencia: si la adaptación empeora seguridad o generalidad, hay que verlo.

Personalización aumenta dependencia. Los ejemplos, hiperparámetros, transformaciones y métricas deben exportarse o documentarse. Si solo existe un artefacto opaco dentro de la plataforma, cambiar de modelo obliga a empezar de nuevo aunque la API prometa variedad.

Contrato cuatro: evaluación ligada al daño

El Marco de Gestión de Riesgos de IA de NIST, publicado en enero de 2023, organizaba el trabajo en gobernar, mapear, medir y gestionar. Insistía en que el riesgo depende del contexto y que las mediciones de laboratorio pueden diferir del funcionamiento real.

Se empieza con una línea base humana o del sistema anterior. Después se crean casos normales, límites y adversariales. Para un resumen contractual se mide omisión de obligaciones, invención, atribución y capacidad de decir que falta información. Para imágenes se añaden derechos, contenido prohibido y correspondencia con el encargo.

El umbral depende del daño. Un borrador que siempre revisa un especialista admite más error que una decisión automática sobre crédito, salud o empleo. La fluidez no compensa una falsa certeza; el indicador prioritario puede ser precisamente cuántos errores graves atraviesan la revisión.

Contrato cinco: operación y recuperación

Una API quita servidores del equipo, no incidentes. La aplicación necesita límites de tiempo y gasto, reintentos idempotentes, circuitos de parada, control de acceso, versiones de prompts y trazas que permitan reconstruir una salida sin almacenar más datos de los necesarios.

Se prepara una ruta degradada: otro modelo aprobado, una función no generativa o intervención humana. Cambiar automáticamente al candidato disponible puede alterar privacidad, coste y conducta. La conmutación es una decisión de producto y riesgo, no solo de disponibilidad.

El seguimiento separa salud técnica y calidad semántica. Latencia y errores HTTP pueden estar bien mientras aumentan las invenciones. Una muestra revisada, quejas, discrepancias y cambios de distribución complementan las métricas de infraestructura.

Contrato seis: la salida

Antes de integrar se ejecuta una prueba de sustitución. ¿Puede otro modelo recibir las entradas, producir el formato, respetar controles y alcanzar el umbral? Se calculan cambios en prompts, embeddings, filtros, evaluaciones, latencia y precio. Una API común reduce algunos costes, no todos.

También se define qué ocurre con modelos personalizados, registros y claves al terminar. La salida incluye borrar, exportar evidencia, revocar permisos y comunicar el cambio. Portabilidad no es que exista un botón para otro modelo, sino poder cambiar sin perder control ni conocimiento.

Bedrock convirtió modelos complejos en servicios más accesibles dentro de AWS. Su valor estaba en absorber infraestructura y facilitar integración. La competencia que conserva el cliente es leer lo gestionado como un reparto explícito: versión, datos, adaptación, evaluación, operación y salida. Solo esos seis contratos convierten una llamada sencilla a una API en un sistema gobernable.