Amazon AWS automatiza la reparación de políticas de Bedrock, pero los humanos conservan la última palabra

Amazon AWS ha añadido dos vías de refinamiento automático para las políticas de Razonamiento automatizado de Bedrock, pese a los riesgos de permitir que el software reescriba su propia lógica de cumplimiento. El sistema puede diagnosticar pruebas fallidas, proponer correcciones formales de reglas y mejorar el lenguaje que se traduce de forma ambigua. Sin embargo, ningún cambio propuesto entra en vigor hasta que una persona lo revisa y acepta.

Ese límite de aprobación es la parte más importante del anuncio. Amazon Bedrock ahora puede realizar más del trabajo de diagnóstico que antes requería que especialistas inspeccionaran manualmente variables, reglas, tipos y resultados de pruebas. AWS está automatizando la propuesta de reparación, no transfiriendo la propiedad de las políticas a un bucle de optimización opaco.

La medida presiona los flujos de trabajo de creación manual de reglas, incluidos los equipos que dependen de hojas de cálculo, verificaciones basadas en prompts o expertos que editan expresiones formales a mano. También pone a prueba una promesa mayor detrás del Razonamiento automatizado: las empresas pueden obtener garantías más sólidas que las de la evaluación convencional de modelos sin convertir cada actualización de política en un proyecto de métodos formales.

Qué cambió Amazon AWS en el refinamiento de políticas de Bedrock

El nuevo flujo de trabajo convierte una prueba de política fallida en una propuesta de reparación revisable, en lugar de dejar a los usuarios únicamente con un resultado de diagnóstico.

Una política de Razonamiento automatizado representa los requisitos del dominio como variables, tipos personalizados y reglas lógicas. Bedrock utiliza esa definición formal para comprobar si una afirmación generada por IA se deriva de los requisitos codificados. Esto difiere de un evaluador basado en modelos, que estima la calidad mediante otro modelo probabilístico.

AWS presentó las comprobaciones de Razonamiento automatizado en versión preliminar durante re:Invent 2024. Posteriormente, el servicio alcanzó la disponibilidad general con gestión de pruebas, generación de escenarios y un manejo ampliado de documentos. AWS afirma que sus comprobaciones de razonamiento pueden procesar material fuente de hasta 120.000 tokens, o aproximadamente 100 páginas.

La capacidad de refinamiento más reciente aborda lo que ocurre después de que los equipos descubren que una política no se comporta como se esperaba. Una prueba puede fallar porque a la regla formal le falta una condición. También puede fallar porque Bedrock asigna el lenguaje ordinario a la variable equivocada o encuentra más de una traducción plausible.

Se trata de clases de fallo distintas, por lo que AWS ofrece dos vías de refinamiento:

• El refinamiento de reglas aborda la estructura formal de la política. Puede proponer adiciones, actualizaciones o eliminaciones relacionadas con reglas, variables y tipos personalizados.

• El refinamiento de lenguaje aborda descripciones ambiguas o imprecisas. Puede revisar las descripciones de variables y las definiciones de tipos para que las traducciones posteriores asignen el lenguaje a los conceptos de política de manera más coherente.

Ambas vías generan cambios propuestos en lugar de sobrescribir inmediatamente la definición activa. En la consola, los usuarios llegan a una pantalla de revisión antes de aceptar el resultado. A través de la API, las aplicaciones recuperan la definición de política generada y luego actualizan explícitamente el borrador.

Esta separación importa porque una reparación sintácticamente válida aún puede codificar una decisión empresarial equivocada. Una política de beneficios para empleados podría compilar correctamente mientras aplica un umbral de antigüedad incorrecto. Una política financiera podría eliminar un conflicto aparente que en realidad representa una excepción intencional.

Por tanto, el anuncio cambia el cuello de botella de autoría, no el modelo de responsabilidad. Bedrock puede inspeccionar el fallo y redactar la reparación. El propietario del dominio sigue decidiendo si la lógica propuesta coincide con la fuente autoritativa.

AWS documenta varios estados posibles del flujo de trabajo, incluidos SCHEDULED, PREPROCESSING, BUILDING, TESTING, COMPLETED y FAILED. El identificador de flujo de trabajo devuelto permite a un cliente supervisar este proceso asíncrono antes de solicitar los activos resultantes.

El servicio también genera un informe de calidad después de una compilación. Ese informe puede identificar problemas estructurales como descripciones ambiguas, grupos de reglas desconectados, variables sin usar y relaciones contradictorias. Estas señales ayudan a los equipos a distinguir un fallo de prueba local de un defecto de modelado más amplio.

Esto crea un ciclo más completo: codificar un documento fuente, ejecutar pruebas, inspeccionar fallos, solicitar una reparación, revisar la definición propuesta y volver a ejecutar la suite. El ciclo ya existía, pero ahora una mayor parte de su trabajo de diagnóstico y traducción se realiza dentro de Bedrock.

El refinamiento de reglas convierte los comentarios de pruebas en cambios formales

El refinamiento de reglas es el modo de mayor impacto porque puede modificar la lógica que determina si una afirmación aprueba o falla.

Consideremos una política de permisos para empleados. El documento fuente indica que un empleado a tiempo completo adquiere el derecho a permiso parental solo después de más de 12 meses de servicio. En cambio, la política generada contiene esta expresión:

Esa regla omite la antigüedad. Una prueba que involucre a un empleado a tiempo completo recién contratado devolvería una aprobación cuando el resultado esperado es una denegación. El fallo no es un problema exclusivamente lingüístico. Al modelo formal le faltan tanto una variable relevante como una condición obligatoria.

AWS describe las anotaciones como correcciones específicas vinculadas a elementos de la política. Las operaciones compatibles incluyen añadir, actualizar o eliminar variables, reglas y tipos personalizados. Un usuario también puede enviar una regla en inglés sencillo mediante addRuleFromNaturalLanguage, lo que permite a Bedrock traducirla a lógica formal.

La definición corregida podría añadir una variable entera denominada tenureMonths y sustituir la expresión original por:

El flujo de trabajo de la consola comienza dentro de la suite de pruebas de la política:

1. Abra una política de Razonamiento automatizado en la consola de Amazon Bedrock.

2. Seleccione una prueba fallida e inspeccione sus resultados.

3. Confirme que las premisas, la afirmación y el resultado esperado representan el escenario previsto.

4. Modifique las condiciones de prueba si la propia prueba está incompleta.

5. Vuelva a ejecutar la prueba para verificar que el escenario revisado expresa el comportamiento esperado.

6. Elija la opción para aplicar anotaciones o refinar la política.

7. Permita que Bedrock inicie un flujo de trabajo de compilación de políticas a partir de los comentarios de la prueba.

8. Revise cada cambio propuesto en reglas, variables y tipos.

9. Acepte los cambios solo cuando coincidan con la política fuente.

10. Vuelva a ejecutar las pruebas guardadas y los escenarios generados frente al borrador revisado.

El tercer y cuarto paso merecen atención. Una prueba fallida no siempre demuestra que la política sea incorrecta. La prueba podría omitir una premisa necesaria, utilizar un resultado esperado inexacto o formular la afirmación de una manera que altere su significado.

Por ello, AWS recomienda inspeccionar el resultado antes de aplicar anotaciones. Su guía de refinamiento indica a los usuarios que modifiquen y vuelvan a ejecutar primero la prueba cuando corresponda. Si la prueba revisada produce el resultado esperado, esos comentarios pueden respaldar una anotación específica.

La API expone la misma capacidad mediante StartAutomatedReasoningPolicyBuildWorkflow. Las reparaciones de reglas utilizan el tipo de flujo de trabajo REFINE_POLICY. La solicitud debe incluir la definición actual completa de la política, no solo el elemento que se modifica.

Una solicitud simplificada de AWS CLI tiene este aspecto:

Una solicitud de producción sustituiría los arrays vacíos por la definición completa del borrador. La versión del esquema de política debe ser 1.0, que es independiente de la versión DRAFT o numerada de la política.

La respuesta satisfactoria contiene dos valores:

La aplicación puede consultar el flujo de trabajo con GetAutomatedReasoningPolicyBuildWorkflow o inspeccionar los flujos de trabajo mediante la operación de listado. Una vez finalizado el procesamiento, recupera la definición de política generada mediante GetAutomatedReasoningPolicyBuildWorkflowResultAssets.

Un comando de recuperación típico sigue este patrón:

La recuperación no convierte la definición propuesta en autoritativa. El cliente debe comparar el resultado con el borrador actual, presentar las diferencias a un revisor autorizado y volver a ejecutar las pruebas pertinentes.

Tras la aprobación, el cliente puede llamar a UpdateAutomatedReasoningPolicy con la definición revisada. Esa actualización explícita es el equivalente en la API de aceptar cambios en la consola.

El flujo de trabajo admite operaciones más precisas que reemplazar a ciegas una política completa. Las anotaciones de variables incluyen addVariable, updateVariable y deleteVariable. Las anotaciones de reglas incluyen addRule, updateRule, deleteRule y addRuleFromNaturalLanguage.

Las operaciones de tipos personalizados cubren adiciones, actualizaciones y eliminaciones. Las anotaciones de comentarios como updateFromRulesFeedback y updateFromScenarioFeedback permiten a los usuarios describir cómo se comportó incorrectamente una regla o un escenario.

Este abanico es útil, pero aumenta la carga de revisión. Eliminar una variable duplicada puede mejorar la coherencia de la traducción. Eliminar una regla de aspecto similar también puede borrar una excepción intencional. Cada propuesta requiere una revisión semántica, incluso cuando la expresión generada supera las comprobaciones estructurales de Bedrock.

El refinamiento de lenguaje corrige la ambigüedad antes de que llegue al solucionador

El refinamiento de lenguaje se dirige al límite donde las frases ordinarias se convierten en premisas y afirmaciones formales, que suele ser la fuente menos visible de los fallos de política.

La lógica formal solo puede evaluar los conceptos que se le proporcionan. Antes de que se produzca esa evaluación, Bedrock debe traducir la entrada de un usuario y una respuesta de IA a las variables definidas por la política.

Las descripciones ambiguas debilitan ese paso de traducción. Supongamos que una política contiene tanto tenureMonths como monthsOfService, con descripciones casi idénticas. La frase “Ella ha trabajado aquí durante dos años” podría asignarse a cualquiera de las dos variables.

La regla subyacente podría ser correcta, pero una prueba aún puede devolver TRANSLATION_AMBIGUOUS. Este resultado significa que el sistema encontró más de una interpretación formal plausible. No significa que la afirmación sea válida o inválida.

El refinamiento de lenguaje examina las descripciones y los tipos personalizados para detectar estas superposiciones. Propone redacciones más claras, conceptos fusionados u otros cambios de definición destinados a reducir la ambigüedad. El objetivo no es el pulido estilístico. Es lograr una asignación más estable entre el lenguaje natural y el esquema formal.

El flujo de trabajo de la consola es más corto que una reparación de regla específica:

1. Abra la política de Razonamiento automatizado en la consola de Bedrock.

2. Vaya a la página Definitions.

3. Inspeccione las advertencias del informe de calidad.

4. Elija Resolve ambiguities.

5. Espere a que Bedrock analice las descripciones de variables y las definiciones de tipos.

6. Revise los cambios de lenguaje propuestos.

7. Compare cada propuesta con el documento fuente original.

8. Acepte solo los cambios que preserven el significado previsto.

9. Vuelva a ejecutar pruebas que contengan redacciones variadas y casos límite.

La API utiliza el mismo endpoint de flujo de trabajo de compilación, pero el tipo de flujo de trabajo es RESOLVE_POLICY_AMBIGUITIES. La solicitud incluye la definición actual completa:

A continuación, el cliente supervisa el flujo de trabajo y recupera la definición propuesta con el tipo de activo POLICY_DEFINITION. También puede recuperar el activo QUALITY_REPORT para comprender qué problemas estructurales motivaron la recomendación.

La API de flujo de trabajo de compilación trata el contenido del flujo de trabajo como una unión. Solo puede aparecer un miembro de contenido compatible en una solicitud. Los clientes no deben combinar contenido de resolución de ambigüedades con otra carga útil de flujo de trabajo y esperar que ambas operaciones se ejecuten juntas.

El refinamiento de lenguaje también difiere de ITERATIVELY_REFINE_POLICY. El flujo de trabajo iterativo utiliza un documento fuente y comentarios opcionales en lenguaje natural para mejorar una política existente. Es adecuado cuando cambia el documento autoritativo o cuando los usuarios desean orientar una mejora más amplia.

Por ejemplo, un manual del empleado revisado podría reducir un umbral de antigüedad y añadir una licencia por duelo. Un cliente puede proporcionar la definición actual completa, el documento actualizado y comentarios que describan esos cambios.

Una solicitud simplificada utiliza esta estructura:

AWS distingue esta operación de INGEST_CONTENT. El refinamiento iterativo utiliza un documento como contexto para mejorar una definición existente. La ingesta extrae nuevas reglas de material nuevo y puede incorporarlas a una política existente.

Esa distinción evita un error de implementación habitual. Un nuevo capítulo del manual normalmente debe incorporarse mediante ingesta. Un capítulo revisado destinado a corregir la lógica existente pertenece al refinamiento iterativo.

La corrección de lenguaje debe seguir probándose con múltiples formulaciones. Una descripción revisada puede eliminar una ambigüedad y crear otra. Los equipos deben incluir sinónimos, términos abreviados, afirmaciones negativas y valores cercanos a los límites de decisión.

Un registro consultable de cláusulas fuente, evidencia de pruebas y revisiones aceptadas también ayuda a los revisores a reconstruir por qué cambió una definición. Los equipos de ingeniería pueden organizar esa evidencia en una base de conocimiento técnica en lugar de separar las decisiones de política de sus documentos de respaldo.

La aprobación humana es la función, no una limitación

El diagnóstico automático reduce el coste del mantenimiento de políticas formales, pero la puerta de aprobación evita que un error de optimización se convierta en una norma organizativa.

La verificación formal a veces se describe como certeza matemática. La expresión necesita un límite: el motor puede razonar rigurosamente sobre la política formal que recibe. No puede garantizar que la política represente perfectamente la legislación, la orientación clínica, los contratos o los procedimientos internos.

Este es el clásico problema de especificación. Un solucionador puede determinar correctamente que una salida se deriva de una regla defectuosa. Las matemáticas validan la coherencia con el modelo, no la veracidad de los supuestos fuente del modelo.

El refinamiento automático no elimina esa limitación. Puede detectar que dos variables se solapan, que un conjunto de reglas está desconectado o que una prueba fallida sugiere que falta una condición. No puede decidir de forma independiente qué interpretación refleja la política legítima de la organización.

Por ello, la pantalla de revisión humana cumple tres propósitos.

Primero, crea control de cambios. Los revisores pueden ver si Bedrock propone una condición añadida, una regla eliminada, una variable renombrada o una definición de tipo modificada.

Segundo, preserva la responsabilidad del dominio. Un ingeniero puede validar la sintaxis y el comportamiento del flujo de trabajo, mientras que un abogado, clínico, responsable de cumplimiento o propietario de la política valida el significado.

Tercero, respalda una pista de auditoría. Los equipos pueden conservar la prueba fallida, la anotación propuesta, la definición aceptada y los resultados posteriores de las pruebas como evidencia de por qué cambió una política.

La propia documentación de AWS recomienda la revisión humana de la información de políticas generada. La extracción a partir de documentos en lenguaje natural no es determinista, por lo que ejecuciones separadas pueden producir diferencias en reglas, variables y tipos.

El modelo operativo más seguro utiliza al menos cuatro controles:

• Exigir la aprobación de un propietario de política identificado para los cambios semánticos.

• Comparar la definición propuesta tanto con la versión actual como con la cláusula fuente.

• Volver a ejecutar la suite completa de regresión, no solo la prueba que activó el refinamiento.

• Publicar una versión numerada de la política únicamente después de completar la revisión y las pruebas.

Las aplicaciones también deben utilizar un token de idempotencia al iniciar flujos de trabajo. El clientRequestToken opcional evita que los reintentos creen operaciones duplicadas cuando se reutiliza el mismo token.

Los límites de los flujos de trabajo también requieren planificación. La documentación de AWS indica que una política admite un máximo de dos flujos de trabajo de compilación, con solo uno en curso a la vez. Un cliente podría necesitar eliminar un flujo de trabajo anterior antes de iniciar otra compilación.

El cifrado y los controles de acceso siguen siendo relevantes porque las definiciones de políticas pueden contener lógica empresarial sensible. Bedrock admite claves AWS KMS administradas por el cliente, pero la identidad que realiza la llamada y la política de claves deben conceder los permisos necesarios de descifrado, descripción y claves de datos.

Estas salvaguardas no convierten el mantenimiento de políticas en algo automático en el sentido habitual. Lo convierten en automatización supervisada. El sistema realiza análisis y genera un artefacto candidato, mientras una persona controla el cambio de estado.

Ese modelo es más defendible que las barreras de protección que se modifican a sí mismas. Si un fallo de producción debilitara automáticamente la regla que lo detectó, los atacantes podrían influir potencialmente en la política mediante entradas elaboradas o comentarios engañosos.

Una puerta de revisión interrumpe esa vía. También permite a los equipos rechazar correcciones que aumentan las tasas de aprobación de pruebas haciendo que la política formal sea menos fiel a su fuente.

La pregunta escéptica es si las organizaciones tratarán la revisión como un control real o como una pantalla de confirmación rutinaria. Las propuestas automáticas pueden generar sesgo de automatización, especialmente cuando los revisores tienen poca experiencia leyendo expresiones formales.

Los equipos deben presentar los cambios propuestos de varias formas: la expresión formal, una explicación en lenguaje sencillo, la cláusula fuente y los escenarios de prueba afectados. Un botón verde de aceptación sin ese contexto trasladaría el cuello de botella en vez de resolverlo.

La presión pasa de redactar lógica a gobernar cambios

Amazon AWS está haciendo más accesible la corrección de políticas formales, pero las organizaciones ahora deben desarrollar prácticas de revisión que se ajusten a la mayor velocidad de cambio.

El competidor inmediato no es una única plataforma en la nube ni un proveedor de modelos. Es la vía manual que utilizan muchos equipos de gobernanza: escribir reglas a mano, inspeccionar los casos fallidos individualmente y depender de un pequeño grupo de especialistas para corregir el modelo formal.

Las barreras de protección basadas en prompts ofrecen otra vía. Pueden indicarle a un modelo que siga una política o pedir a un segundo modelo que evalúe el cumplimiento. Estos métodos son más fáciles de iniciar, pero sus decisiones siguen siendo probabilísticas y pueden variar según la redacción o las versiones del modelo.

Automated Reasoning utiliza variables y restricciones explícitas. Esa estructura permite contraejemplos, análisis de satisfacibilidad y hallazgos auditables. También requiere una especificación fiel, lo que genera más trabajo de configuración y mantenimiento.

El refinamiento apunta a ese coste de mantenimiento. Si Bedrock convierte de manera fiable los comentarios de las pruebas en parches acotados y revisables, los expertos del dominio pueden dedicar menos tiempo a traducir el lenguaje habitual de las políticas en expresiones para solucionadores.

Un caso de cliente de AWS comunicado ilustra el resultado previsto. El proveedor de servicios financieros PitCrew afirma que codificó 40 políticas de Automated Reasoning y utiliza combinaciones de ellas en tres agentes de producción. Su flujo de trabajo de cumplimiento verifica materiales de marketing y formularios regulatorios frente a restricciones formales.

Según la empresa, un proceso de revisión pasó de dos semanas a 30 minutos. Se informa que el contenido de marketing y redes sociales que antes entraba en una cola de tres días se aprueba en 30 segundos. Estos son resultados comunicados por el cliente de una implementación específica, no garantías generales de rendimiento.

El caso de uso revela por qué importa el refinamiento. El material regulatorio cambia, las políticas de los clientes difieren y surgen casos límite después del despliegue. Una política que no pueda corregirse eficientemente se quedará obsoleta o acumulará excepciones manuales fuera del sistema formal.

Sin embargo, una corrección más rápida también puede aumentar la rotación de políticas. Un equipo podría aceptar correcciones locales frecuentes sin comprobar cómo afecta cada cambio a otros grupos de reglas. Con el tiempo, la definición puede volverse internamente coherente, pero difícil de comprender para las personas.

El informe de calidad puede ayudar a identificar conjuntos de reglas desconectados, elementos en conflicto y descripciones ambiguas. No puede sustituir la disciplina de versionado ni las pruebas de regresión.

Las organizaciones que evalúen la función deberían medir más que el número de sugerencias aceptadas. Entre los indicadores útiles se incluyen:

• El porcentaje de cambios propuestos aceptados sin modificaciones.

• El porcentaje rechazado por alterar el significado previsto.

• Los fallos de regresión introducidos por una corrección aceptada.

• La ambigüedad de traducción entre formulaciones realistas de los usuarios.

• El tiempo desde una prueba fallida hasta una actualización de política revisada.

• Las diferencias entre las aprobaciones del propietario del dominio y del ingeniero.

Estas medidas revelan si el refinamiento reduce el trabajo de los expertos o simplemente lo desplaza a la revisión. También exponen casos en los que el motor propone repetidamente cambios plausibles pero semánticamente incorrectos.

La función debería ser especialmente relevante para aplicaciones reguladas, donde las reglas tienen fuentes autoritativas y las decisiones necesitan explicaciones. La elegibilidad sanitaria, las divulgaciones financieras, los beneficios para empleados, la cobertura de seguros y los requisitos contractuales encajan en ese patrón.

Es menos adecuada para preferencias amplias como «ser útil» o «redactar contenido atractivo». Esos objetivos carecen de las variables y restricciones precisas necesarias para una evaluación formal.

La principal disyuntiva sigue siendo capacidad frente a gobernanza. La corrección automática amplía quién puede participar en el desarrollo de políticas. También incrementa el número de cambios que los revisores podrían aprobar sin rastrear plenamente sus consecuencias.

Qué observar después de que Amazon AWS automatice el refinamiento

La próxima prueba será si las propuestas de Bedrock siguen siendo acotadas, explicables y fieles cuando las políticas superen los ejemplos controlados.

La primera señal es la calidad de aceptación en despliegues reales. AWS debería mostrar con qué frecuencia los expertos del dominio aceptan las correcciones propuestas sin cambios, las revisan o las rechazan. Una alta aceptación acompañada de resultados de regresión estables respaldaría la afirmación de que el refinamiento reduce el trabajo de autoría formal.

Una alta tasa de rechazo sugeriría que el diagnóstico es útil, pero que la corrección semántica sigue siendo trabajo de especialistas. La aceptación por sí sola es insuficiente porque los revisores pueden aprobar malas sugerencias. Los resultados deben incluir regresiones y hallazgos posteriores en producción.

La segunda señal es la evidencia procedente de políticas grandes y conectadas. Los ejemplos publicados utilizan reglas comprensibles, como la elegibilidad para permisos y la evaluación de riesgos hospitalarios. Las definiciones empresariales pueden contener excepciones, referencias cruzadas, tipos personalizados y requisitos que interactúan entre muchas secciones.

Una corrección que soluciona un escenario fallido puede cambiar las consecuencias de varias reglas distantes. Las pruebas deben revelar si el motor identifica ese impacto más amplio y si su interfaz de revisión hace visibles esos efectos.

La tercera señal es cómo AWS amplía la integración y la gobernanza. Las incorporaciones útiles incluirían diferencias de políticas más detalladas, roles de aprobación, revisores obligatorios, trazabilidad de las cláusulas fuente y vínculos más claros entre los cambios aceptados y las pruebas afectadas.

La gobernanza entre cuentas también merece atención. AWS ha ampliado las salvaguardas centralizadas de Bedrock, pero ha documentado limitaciones relacionadas con las comprobaciones de Automated Reasoning en algunos escenarios de aplicación entre cuentas. Un soporte más amplio determinaría si las grandes organizaciones pueden gobernar estas políticas de forma coherente entre equipos.

Para los desarrolladores, la acción inmediata es práctica. Empiecen con una política acotada, preserven el documento autoritativo y creen pruebas para aprobaciones esperadas, denegaciones, ambigüedad y condiciones límite. Activen el refinamiento de reglas solo después de confirmar que la propia prueba es correcta.

Después, revisen cada propuesta como una decisión de política, no como una comodidad de generación de código. Recuperen la definición de la política y el informe de calidad, compárenlos con el borrador actual, vuelvan a ejecutar la suite completa y versionen el resultado aceptado.

Para los compradores empresariales, pregunte quién aprueba los cambios y cómo se registran las propuestas rechazadas. Pregunte si los revisores ven conjuntamente diferencias formales, explicaciones en lenguaje sencillo, evidencia de las fuentes e impacto en las regresiones.

Amazon AWS ha acortado el camino desde el fallo hasta una posible corrección. La cuestión más difícil sigue siendo organizativa: ¿puede su equipo revisar cambios formales de políticas con el mismo rigor con que Bedrock ya puede generarlos?