Cómo Wiixt lleva los procedimientos de seguridad a los trabajadores de campo con un agente de voz con IA en AWS

Los trabajadores de campo en tareas de alto riesgo rara vez tienen las manos libres para buscar en un manual. Para Wiixt, una empresa de software de salud y seguridad ocupacional en América Latina, esa brecha significaba que los procedimientos de seguridad y el reporte de incidentes vivían en una pantalla que los trabajadores no siempre podían usar. Junto a Craftech, AWS Advanced Tier Services Partner, Wiixt lanzó un agente de voz en español construido con Amazon Transcribe, Amazon Bedrock con Claude Haiku 4.5 y Amazon Polly. Ahora los trabajadores pueden preguntar por un procedimiento y escuchar una respuesta con su fuente, o presentar un reporte de incidente por voz.

Sobre Wiixt

Wiixt es una empresa de software cuya plataforma SaaS da soporte a programas de salud y seguridad ocupacional. Sus usuarios son trabajadores y supervisores que completan los cursos de seguridad asignados, consultan procedimientos y reportan incidentes a través de la plataforma. Cada trabajador ve solo los cursos, formularios y datos habilitados para él.

El desafío

La plataforma no tenía un canal de voz. Sumarlo planteaba requisitos que un chatbot estándar no enfrenta:

• Conversación manos libres y de baja latencia. Un trabajador en el campo necesita un intercambio hablado natural, no una pausa de varios segundos después de cada pregunta.
• Respuestas basadas en los documentos correctos. Una respuesta de seguridad tiene que salir de los procedimientos asignados a ese trabajador, con una referencia que pueda verificar.
• Permisos por usuario por fuera del modelo. El agente nunca debe recuperar contenido ni abrir un formulario al que el trabajador no tiene acceso, sin importar lo que se le pida.
• Acciones confiables. Un reporte de incidente o se presenta con un número de reporte real, o queda claro que no se presentó. El agente no puede anunciar un éxito que no logró.
• Seguridad antes de hablar. Una vez que una frase se dice, el trabajador ya la escuchó. Cualquier control tiene que ocurrir antes de la síntesis de voz, dentro del margen de latencia.

La solución: un agente de voz con controles por fuera del prompt

Craftech construyó el agente sobre el SDK open source LiveKit Agents, con servicios de AWS a cargo de cada etapa de la conversación.

El pipeline de voz

Amazon Transcribe en streaming convierte la voz en texto. Amazon Bedrock con Claude Haiku 4.5 se encarga del razonamiento y decide qué herramienta llamar. Amazon Polly responde en voz. La detección de actividad de voz, la detección de fin de turno y la generación anticipada acortan el silencio entre turnos, y el prompt caching de Bedrock cubre el prompt de sistema y las definiciones de herramientas para que no se reprocesen en cada turno.

Runtime gestionado

El agente corre en Amazon Bedrock AgentCore Runtime, cuyo authorizer JWT integrado valida cada token entrante antes de que el agente se ejecute. El rol de ejecución sigue el patrón de referencia de AWS, con la relación de confianza restringida por cuenta de origen y ARN de origen.

Autorización en el código, no en el prompt

El token de identidad del trabajador viaja con cada llamada al backend. La recuperación se filtra por los cursos asignados a ese trabajador, las herramientas de analítica se registran solo cuando el trabajador tiene datos para consultar, y cada pedido de formulario se verifica contra los módulos habilitados del trabajador antes de abrirse. El estado de la conversación se indexa por usuario y por sala, así que una sesión nunca reutiliza el contexto de otra.

Respuestas con fundamento

Una búsqueda híbrida sobre un índice vectorial de Weaviate devuelve fragmentos de procedimientos de los propios cursos del trabajador, ampliados con el contexto vecino. Cada respuesta sobre un procedimiento incluye la página de origen y un link al documento.

Reporte de incidentes confiable

El agente completa el reporte campo por campo a medida que el trabajador habla, y guarda el estado parcial en Amazon DynamoDB. Un reporte cuenta como presentado solo cuando el formulario está completo y el backend devuelve un número de reporte real. Ante cualquier falla, el agente tiene la instrucción de decir que el reporte no se presentó.

Analítica segura

Cuando un trabajador pregunta por sus datos, el SQL generado corre contra una copia en memoria de SQLite, propia de cada conversación, y nunca contra la base de datos en vivo. La validación de solo lectura y el modo query-only de SQLite suman dos resguardos independientes.

Controles de seguridad antes de hablar

Amazon Bedrock Guardrails, aplicado a través de su API de evaluación independiente, revisa cada transcripción antes de que llegue al modelo y cada frase de la respuesta antes de sintetizarla. La política cubre detección de ataques al prompt, temas prohibidos, grounding contextual, filtros de palabras y manejo de datos personales (PII).

El prompt de sistema suma la postura de seguridad del agente: nunca autoriza trabajos, siempre cita su fuente y escala a un supervisor las situaciones de riesgo grave. La trazabilidad corre en Langfuse sobre OpenTelemetry, junto con Amazon CloudWatch Logs y las métricas nativas de Bedrock.

Resultados

El agente está en producción desde enero de 2026 y les da a los trabajadores un canal de voz que la plataforma no tenía.

• Un canal nuevo, manos libres. Los trabajadores pueden consultar procedimientos y presentar reportes de incidentes por voz, en español, sin navegar una pantalla.
• Turnos más rápidos gracias a iteraciones medidas. La instrumentación por etapa mostró que el tiempo hasta el primer token del modelo era la mayor parte de cada turno. A lo largo de las iteraciones de desarrollo en un entorno de QA, la latencia mediana de un turno en caliente bajó de 5,3 s a 2,9 s, cerca de un 46% más rápido.
• Respuestas con fuente. Cada respuesta sobre un procedimiento cita la página y el documento de donde salió, filtrado a los cursos asignados al trabajador.
• Permisos aplicados en tiempo de ejecución. El alcance de la recuperación, el acceso a formularios y el acceso a analítica se verifican en el código en cada pedido, independientemente de lo que decida el modelo.
• Sin confirmaciones falsas. Un reporte se anuncia como presentado solo cuando el backend devuelve un número de reporte real.
• Mejoras a partir del uso real. Cuando el uso en producción mostró que el agente ofrecía formularios que el trabajador no podía presentar, el equipo sumó la validación de módulos en el código en lugar de depender de la redacción del prompt.

Lecciones aprendidas

• Una vez resuelta la precisión, la restricción es la latencia. La generación anticipada, el caching, la precarga y la elección del modelo actúan cada uno sobre una parte distinta del turno. Solo la medición por etapa muestra cuál conviene ajustar.
• La autorización va en controles ejecutables. Las instrucciones del prompt describen el comportamiento deseado; los filtros por curso, las verificaciones de módulos y el registro condicional de herramientas lo garantizan.
• La voz no tiene deshacer. Lo que se sintetiza ya se escuchó, así que los controles de seguridad tienen que correr antes de hablar y su costo tiene que entrar en el margen de latencia.
• Reconocer explícitamente le gana al optimismo. El estado de conversación aislado y una regla estricta contra anunciar un éxito sin número de reporte hacen que las fallas sean visibles y comprensibles.

Próximos pasos

Con el canal de voz en funcionamiento, los próximos pasos son medir la latencia y el costo por conversación frente a la configuración actual de producción, y ampliar los tests de punta a punta del sistema desplegado.