Artículo
Claude en Bedrock: respuestas estructuradas
AWS anunció el 19 de octubre la disponibilidad general de respuestas estructuradas para Claude en Amazon Bedrock, con JSON Schema y restricciones estrictas para parámetros de herramientas.
JSON agrupa datos en campos; el esquema define tipos como texto o número.
Para un equipo que conecta mensajes con una operación, la pregunta práctica es qué puede avanzar automáticamente y qué necesita una comprobación. Propongo mirarlo como una recepción con formularios: ordenar las casillas ayuda a procesar una solicitud, pero todavía hay que comprobar quién la envió, qué pidió y si corresponde atenderla.
Un formulario bien llenado todavía necesita contexto
Imagina una reserva de equipos para un evento. El formulario contiene nombre, fecha, cantidad y lugar de entrega. Todas las casillas están completas y la cantidad tiene apariencia de número. Sin embargo, el cliente podría haber escrito una fecha pasada o mencionado una dirección que el negocio no atiende. La hoja está ordenada; la reserva sigue pendiente de verificación.
Esta distinción permite repartir responsabilidades. Una comprobación revisa si llegó la información con la forma esperada. Otra contrasta lo escrito con la solicitud original y los registros del negocio. Una tercera decide si existe permiso para realizar la acción. Conviene definir las tres antes de conectar la respuesta con una agenda, un pedido o un mensaje al cliente.
AWS advierte sobre rechazos, respuestas truncadas y restricciones del esquema que requieren validación en la aplicación.
Diseña los campos desde la decisión que quieres tomar
En este ejercicio, la empresa de arriendo quiere preparar una propuesta de reserva. Primero necesita saber qué equipos solicita la persona y cuándo los requiere. La confirmación llegará después de consultar disponibilidad. Ese límite evita pedirle al primer paso una conclusión que todavía depende de información externa.
Yo separaría lo que la persona declaró de lo que el negocio comprobó. La fecha solicitada pertenece al primer grupo. La existencia de equipos disponibles pertenece al segundo. Mezclarlos en una misma casilla llamada reserva confirmada escondería quién aportó cada dato y qué falta resolver. Dos valores parecidos pueden tener consecuencias distintas.
También dejaría un lugar para la incertidumbre. Si el mensaje dice el próximo viernes, el responsable debe aclarar a qué fecha se refiere antes de comprometer una entrega. Completar el casillero con una suposición haría más limpia la pantalla, pero trasladaría el problema a quien prepara los equipos. Un pendiente explícito es una instrucción de trabajo útil.
Recorre una reserva ficticia hasta su aceptación
El siguiente ejemplo es una propuesta pedagógica original. No representa una implementación de AWS, un cliente real ni resultados medidos. Una persona solicita doce sillas para una actividad y luego corrige la cantidad a veinte. El equipo conserva ambos mensajes para decidir cuál expresa la petición vigente.
| Información recibida | Comprobación propuesta | Siguiente decisión |
|---|---|---|
| Cantidad: veinte sillas | Contrastar con la última corrección del solicitante | Preparar consulta de disponibilidad |
| Fecha: viernes | Pedir una fecha completa si existe ambigüedad | Mantener la reserva pendiente |
| Dirección de entrega | Consultar la zona que atiende el negocio | Proponer entrega o retiro |
| Solicitud de confirmación | Verificar disponibilidad y autorización del responsable | Confirmar o explicar la alternativa |
La tabla organiza preguntas distintas. La última corrección sirve para interpretar la intención; el inventario sirve para comprobar disponibilidad. Ninguna de esas tareas equivale a autorizar una entrega. Para este negocio ficticio, quien revise debería poder ver la solicitud, la comprobación y la decisión sin reconstruirlas desde una conversación dispersa.
Si alguien cambia veinte por doscientas sillas, propongo detener la confirmación y solicitar revisión. El motivo sería una regla acordada por ese negocio, no una propiedad atribuida al modelo. Documentar quién puede cambiar esa regla importa tanto como elegir el número. Así el equipo puede discutir una decisión concreta en vez de confiar en una etiqueta genérica de validado.
La acción necesita permiso y una salida humana
Antes de activar una confirmación, distinguiría dos preguntas: si la persona pidió esa reserva y si autorizó el contacto por el canal elegido. Un teléfono presente en un mensaje no responde por sí solo ambas preguntas. En el diseño propuesto, el sistema conservaría la evidencia pertinente y dejaría pendiente cualquier autorización que no pudiera comprobar.
La derivación humana debería incluir una razón que permita trabajar. Cantidad corregida, fecha ambigua o disponibilidad sin confirmar son motivos concretos. Enviar únicamente revisar obliga al equipo a empezar de nuevo. También asignaría un responsable y definiría qué puede hacer mientras falta una respuesta, por ejemplo preparar un borrador sin enviarlo.
Tras una interrupción, el responsable consultaría el estado real de la reserva antes de intentar confirmarla otra vez. Si ya existe una confirmación, la tarea sería comprobarla y comunicar su estado. Este criterio propuesto busca evitar duplicaciones; aquí no se ha construido ni probado una automatización.
Evalúa el recorrido completo antes de ampliarlo
Para revisar este diseño, prepararía solicitudes ficticias con correcciones, fechas incompletas, equipos inexistentes y respuestas que no permiten continuar. Cada caso tendría una decisión esperada por escrito. El objetivo sería comprobar dónde se detiene el recorrido, qué información recibe la persona responsable y si la confirmación puede ocurrir sin las comprobaciones acordadas.
Contaría por separado los formularios aceptados, los datos corregidos y las reservas finalmente autorizadas. Sumarlos en una sola cifra ocultaría qué parte del trabajo funcionó. Una evaluación útil también incluiría el tiempo de revisión y los casos que quedaron pendientes; cualquier comparación posterior necesitaría una base de referencia y condiciones equivalentes.
La lectura sobre Mercury: rapidez con criterio ofrece otra entrada para pensar la calidad de una respuesta. Para revisar cómo se relacionan herramientas y gasto, puedes continuar con HubSpot: puestos, créditos y control del gasto.
Fuente: anuncio de AWS del 19 de octubre de 2026.
Preguntas frecuentes
¿Qué significa que la forma sea válida?
En la analogía, significa que el formulario respeta las casillas acordadas. Para aceptar una reserva todavía proponemos contrastar su contenido con la petición y la disponibilidad. Son comprobaciones con responsables y evidencias diferentes.
¿Qué automatizaría primero?
En el ejemplo, la preparación de un borrador de reserva con sus pendientes visibles. La confirmación quedaría separada hasta comprobar los requisitos del negocio. Esa elección permite revisar el trabajo antes de comprometer una entrega.
¿Qué haría si falta información?
Dejaría constancia del dato pendiente y pediría una aclaración concreta. La persona responsable debería recibir el motivo y el contexto necesario. Inventar una fecha para completar la pantalla impediría distinguir una solicitud de una suposición.
¿Cómo decidir cuándo ampliar el uso?
Revisaría los casos acordados, las correcciones humanas y los pendientes. El equipo tendría que aceptar el comportamiento observado y sus límites antes de ampliar el alcance. Este artículo propone criterios; no presenta una prueba operativa ni una garantía.
Trae a Comunidad IA un proceso que hoy dependa de copiar datos. Podemos discutir qué decisión necesita evidencia, quién debería aprobarla y dónde conviene detener el recorrido para revisar.
