Artículo
PC2: compromisos verificables para agentes de IA
Ciliberto, Rudi y Tassi presentaron PC2, contratos con pruebas para agentes, en un preprint enviado a arXiv el 20 de octubre de 2026.
Para entender la pregunta, imaginemos una organización que delega una compra. Quiere obtener lo necesario, respetar un presupuesto y conservar ciertas condiciones. Esa escena ficticia sirve para explorar qué significa aceptar una acción con razones comprobables. Los ejemplos siguientes son elaboración didáctica propia.
Un compromiso necesita una condición que podamos examinar
En este ejercicio, llamaremos contrato al conjunto de condiciones acordadas para una tarea. Usamos la palabra como definición de trabajo, sin atribuirle validez jurídica. Antes de discutir tecnología, el equipo debería poder explicar qué quiere conservar y sobre qué objetos se aplica cada condición.
Pensemos en una academia ficticia que necesita ocho cuadernos para un taller. «Compra bien» deja demasiado espacio a interpretaciones. Para nuestro ejercicio, una condición más precisa sería: el costo completo debe caber en el saldo asignado e incluir la entrega. Otra sería: ningún pedido puede incorporar una suscripción.
Estas decisiones tienen responsables humanos. Alguien debe definir el saldo, identificar la moneda y resolver qué significa entrega incluida. Un sistema que comprobara perfectamente una condición equivocada seguiría respondiendo a una pregunta mal elegida. Por eso empezaríamos revisando el acuerdo con quien conoce la necesidad, antes de evaluar cualquier automatización.
Una prueba debe responder exactamente a la pregunta acordada
En PC2, las partes fijan las condiciones y el agente aporta una prueba comprobable por máquina para la operación solicitada. Airlock verifica esa prueba y controla el acceso. La comprobación abarca los casos permitidos por el modelo; no cualquier situación real imaginable.
Como analogía educativa, supongamos que una persona propone un pedido y otra revisa su cálculo. El precio de los cuadernos cabe en el saldo, pero falta el transporte. El cálculo parcial puede ser correcto; todavía no responde a la condición completa. Esta distinción permite entender por qué importa especificar qué se está demostrando.
En nuestra explicación, una prueba es un razonamiento que justifica una afirmación bajo premisas explícitas. Comprobar una suma es un ejemplo cotidiano y limitado. No equivale a construir una prueba formal sobre un agente, ni describe el lenguaje o las reglas usados en la investigación.
Para conversar con un proveedor pediríamos que escribiera la propiedad, sus premisas y el procedimiento que acepta o rechaza la justificación. Así podríamos discutir una afirmación concreta. Una explicación extensa en lenguaje natural puede ayudarnos a comprender una propuesta, pero no sustituye por sí sola el criterio de aceptación que decidimos exigir.
Ejemplo ficticio: una compra que respete el saldo completo
Construyamos un caso pequeño con unidades monetarias inventadas. La academia dispone de 100 unidades. Los ocho cuadernos cuestan 72 y la entrega, 15. La siguiente tabla es una herramienta de aprendizaje original: sus cifras no provienen del paper y ninguna compra fue ejecutada.
| Propuesta imaginaria | Cálculo del ejercicio | Decisión razonada |
|---|---|---|
| Cuadernos con entrega incluida | 72 + 15 = 87 | Cabe en 100 bajo los datos supuestos |
| Cuadernos con entrega de 35 | 72 + 35 = 107 | No cumple el límite del ejercicio |
| Cuadernos sin precio de entrega | Total desconocido | Falta información para decidir |
La tercera fila enseña algo diferente del rechazo: no tenemos un total. Es importante conservar esa incertidumbre. Si la academia decide que sólo acepta propuestas con costo completo conocido, podrá detener la compra pendiente de información. No necesitará inventar una tarifa para llenar la casilla.
También revisaríamos el objeto del acuerdo: ¿100 unidades por pedido o para todo el taller? Dos pedidos de 87 cabrían individualmente y superarían juntos un presupuesto de 100. Es una pregunta del ejemplo sobre cómo formular condiciones, sin afirmar qué mecanismo utiliza PC2 para representar o resolver esa situación.
El mundo representado puede dejar información fuera
Sigamos dentro del caso ficticio. Un documento podría indicar entrega de 15 y otro mostrar un recargo. Si el ejercicio sólo considera el primer documento, su suma no resuelve la discrepancia. Conviene distinguir un razonamiento correcto sobre datos asumidos de una observación suficiente para decidir una compra real.
Imaginemos además que los cuadernos llegan dañados. Nuestro criterio presupuestario no había definido calidad física. Cumplir ese criterio no autorizaría a declarar que toda la compra fue satisfactoria. Podríamos añadir una condición nueva, pero tendríamos que explicar cómo observarla y quién la acepta.
Una buena discusión de confiabilidad pregunta tanto por el razonamiento como por la representación elegida. ¿Qué datos entran? ¿Cuáles cambian? ¿Qué situaciones excluimos deliberadamente? Plantear esas preguntas evita que una propiedad limitada se convierta, por una frase demasiado amplia, en una promesa sobre cualquier consecuencia imaginable.
Segundo ejemplo ficticio: compartir materiales con un destinatario acordado
Cambiemos de escenario para explorar una condición que no depende de sumar. Una biblioteca inventada prepara material de práctica para una colaboradora llamada Elena. El equipo decide que una carpeta ficticia puede compartirse con esa persona y que un borrador interno debe quedar fuera. No usamos identidades ni archivos reales.
| Condición imaginaria | Dato que revisaríamos | Pregunta pendiente |
|---|---|---|
| Destinataria acordada | Identificador de Elena en el ejercicio | ¿Corresponde a la persona prevista? |
| Material delimitado | Lista exacta de documentos ficticios | ¿Quedó fuera el borrador interno? |
| Entrega acotada | Permiso propuesto para esa carpeta | ¿Incluye otras carpetas por herencia? |
La tabla organiza preguntas; no es un verificador ni una prueba formal. Para convertirla en una comprobación técnica harían falta definiciones y una implementación que aquí no presentamos. Su utilidad educativa consiste en revelar que «compartir correctamente» reúne varias propiedades diferentes.
Podríamos comprobar la identidad prevista y seguir sin saber qué archivos contiene la carpeta. O conocer los archivos y desconocer el alcance del permiso. En la conversación del equipo conservaríamos ambas incertidumbres por separado, para que una respuesta favorable no oculte la pregunta que todavía falta resolver.
Confiar requiere distinguir intención, justificación y resultado
En ambos ejercicios proponemos tres preguntas: qué acción se desea, por qué sería aceptable y qué se observó después. La intención explica el objetivo; la justificación relaciona la propuesta con condiciones; el resultado permite examinar lo ocurrido. Ninguna de estas preguntas debería desaparecer porque otra recibió una respuesta convincente.
Esta distinción ayuda a conversar sin exageraciones. Para aprender, podríamos pedir a una persona que defienda la compra y a otra que busque una premisa omitida. Después compararíamos sus argumentos con las condiciones escritas. Sería un taller de razonamiento, sin asumir que reproduce una evaluación de agentes.
Si quieres ampliar la pregunta sobre quién actúa, puedes leer la explicación sobre identidad de agentes y NIST. Para examinar cómo se presentan capacidades, está Toolflation y las promesas de herramientas. Son lecturas relacionadas; no aportan validación experimental a esta propuesta.
Qué podemos leer y qué necesitamos investigar después
Los autores afirman conservar restricciones durante la ejecución bajo su modelo. Esta lectura no verifica las demostraciones completas.
Esta noticia utiliza exclusivamente la ficha bibliográfica y el abstract. No revisamos el protocolo completo, las demostraciones ni una implementación. No acreditamos disponibilidad comercial, desempeño o funcionamiento en producción. Para evaluar técnicamente la propuesta sería necesario estudiar el artículo íntegro y las condiciones exactas de sus resultados.
Desde una decisión organizacional, preguntaríamos qué propiedad interesa proteger y qué evidencia permitiría evaluarla. También pediríamos identificar premisas, componentes de confianza y situaciones excluidas. Son preguntas para una revisión posterior, no respuestas inferidas desde el título ni instrucciones de instalación.
Una práctica útil: escribir el compromiso antes de delegar
Prueba el ejercicio con una tarea inventada. Escribe una condición, agrega un caso que la incumpla y otro en el que falte información. Si no puedes decidir qué debería ocurrir en cada uno, revisa primero la condición. Así conviertes una expectativa difusa en una conversación que otras personas pueden examinar.
Luego pide a alguien que encuentre una ambigüedad: el costo acumulado, la identidad del destinatario o un documento fuera de alcance. El objetivo del taller sería mejorar la pregunta y reconocer sus límites. No se trata de certificar un sistema mediante una tabla.
Consulta la ficha primaria en arXiv y continúa el aprendizaje en la Comunidad IA. Lleva un escenario ficticio y una condición concreta para conversar sobre qué aceptarías como evidencia.
