Ocho pruebas que ejecuta usted mismo, en su propia instalación.

1Soberanía: los datos protegidos nunca salen del perímetro

Afirmación bajo prueba. Una petición que enviaría datos clasificados como soberanos a un modelo en la nube se rechaza dentro del perímetro con 403 SOVEREIGNTY_BLOCK…, antes de que salga ningún paquete.

Preparación

1. Admin → Workspaces → cree pov-sovereign, clasificación de datos Sovereign.
2. Admin → AI Gateway → compruebe que hay configurado al menos un nivel en la nube (cualquier proveedor) y un nivel local.
3. Suba al conocimiento de ese espacio un documento con una cadena secreta reconocible (por ejemplo POV-SECRET-4711).
4. Empiece a capturar la salida en el perímetro, filtrada a los hosts del proveedor en la nube.

Pasos

1. En Chat, en el espacio pov-sovereign, seleccione el nivel Cloud Reasoning y pregunte: «¿Cuál es el secreto del documento subido?»
2. Repita por la API para ver el código exacto:

   curl -s -H "Cookie: $COOKIE" -H 'content-type: application/json' \
     -d '{"workspaceId":"pov-sovereign","modelTier":"cloud-reasoning","dataClassification":"sovereign","message":"What is the secret?"}' \
     $GW/chat/message -o /dev/null -w '%{http_code}\n'

3. Cambie al nivel Local y haga la misma pregunta.
4. Admin → Governance → registro de auditoría: filtre por la acción sovereignty.data_classification.

Observables

• Paso 1: la interfaz rechaza con el mensaje de soberanía; no se produce ninguna respuesta.
• Paso 2: HTTP 403, cuerpo code: SOVEREIGNTY_BLOCK_DATA_CLASSIFICATION.
• Paso 3: el nivel local responde con el secreto y una cita al documento.
• Paso 4: una fila de auditoría por rechazo con el espacio, el usuario y la regla sovereign-data-cloud-tier.
• Captura en el perímetro: cero conexiones al proveedor en la nube durante los pasos 1 y 2. Este es el observable que importa; el 403 por sí solo demuestra que la puerta existe, la captura demuestra que está antes de la salida.

Aprobada: los cinco observables. No demuestra: que todas las rutas de código estén protegidas; eso lo acumulan la fila de auditoría y la captura en el resto de sus pruebas (2, 5).

Variante B (air gap)

Instale el paquete air gap con AANCER_OFFLINE_INSTALL=1 en un host cuyo cortafuegos deniegue todo el tráfico saliente. Arranque, inicie sesión, ejecute la prueba 5. Esperado: la plataforma es plenamente usable con modelos locales, la licencia se activa desde el token sin conexión y el registro del cortafuegos no muestra ningún intento saliente desde los hosts de la plataforma (no hay llamadas a casa).

2Seguridad de agentes: una acción no autorizada se deniega técnicamente, no solo se desaconseja

Afirmación bajo prueba. Las herramientas de un agente están acotadas por su pasaporte firmado (alcance, techo de clasificación, presupuesto) y por el asiento. Una llamada a herramienta fuera del sobre la rechaza la plataforma con un resultado PolicyDenied que el modelo no puede esquivar con palabras, y el rechazo se audita.

Preparación

1. Agents → Design → cree pov-agent con dos herramientas: una de lectura (por ejemplo Buscar en el conocimiento) y una de acción (por ejemplo Añadir al dataset, o cualquier escritura de conector que tenga).
2. Certifíquelo (Agent Administration → Certificados → Emitir) con un techo de clasificación internal y alcance limitado solo a la herramienta de lectura.
3. Cree un dataset pov_actions en un espacio interno y un segundo en el espacio pov-sovereign de la prueba 1.

Pasos

1. Como Platform Admin, converse con pov-agent en el espacio interno: «Añade una fila {note:'hello'} al dataset pov_actions.» (La herramienta de escritura está vinculada al agente pero no dentro del alcance del pasaporte.)
2. Después: «Busca POV-SECRET en el conocimiento.» (dentro del alcance).
3. Vuelva a emitir el pasaporte con la herramienta de escritura dentro del alcance; repita el paso 1.
4. Ahora converse con el mismo agente desde el espacio pov-sovereign y pídale que busque en el conocimiento.
5. Como asiento Knowledge Worker (sin agent.execute_code), pida a cualquier agente que tenga la herramienta Ejecutar código que «calcule 2**64 exactamente».
6. Admin → Governance → registro de auditoría: filtre agent.tool.call.

Observables

• Paso 1: el agente informa de que no puede realizar la acción; la traza de la ejecución muestra la llamada con resultado PolicyDenied / envelope.out_of_scope; no se escribió ninguna fila (compruebe el dataset).
• Paso 2: tiene éxito, se muestra la cita.
• Paso 3: la fila se escribe; la traza muestra allowed.
• Paso 4: PolicyDenied / sovereignty.classification_ceiling; el espacio soberano está por encima del techo internal del pasaporte; no se recuperó nada.
• Paso 5: la herramienta de código se deniega para el asiento (permiso), el agente responde sin ella.
• Paso 6: una fila de auditoría por llamada a herramienta con outcome: denied y la regla de decisión anterior; las filas denegadas no llevan argumentos de herramienta más allá de sus nombres.

Aprobada: los seis. No demuestra: el criterio del modelo; demuestra que la plataforma no depende de él.

3Revocación: un pasaporte revocado se detiene en menos de 30 segundos

Afirmación bajo prueba. Revocar el certificado de un agente detiene la ejecución de más herramientas en 30 s (la plataforma cachea las comprobaciones de revocación como máximo 30 s); la comprobación falla cerrada si el almacén de revocaciones no está accesible.

Preparación

pov-agent de la prueba 2, certificado, con un flujo o una instrucción que le haga llamar a una herramienta repetidamente (por ejemplo «busca en el conocimiento cada uno de estos 40 términos, una llamada por término»).

Pasos

1. Inicie la conversación larga y anote la hora (T0).
2. Mientras se ejecuta: Agent Administration → Certificados → el certificado del agente → Revocar (o POST $GW/admin/agent/certs/<lid>/revoke). Anote T1.
3. Observe la traza; anote la marca de tiempo de la última llamada permitida (T2) y del primer PolicyDenied / revoked (T3).
4. Inicie una conversación nueva con el agente revocado.
5. Comprobación opcional de fallo cerrado (Docker): docker stop <postgres> durante 20 s en mitad de una ejecución.

Observables

• T3 − T1 ≤ 30 s; toda llamada posterior a T3 se deniega; la ejecución termina con un error honesto, no con un bloqueo.
• Paso 4: rechazado de inmediato: «Invalid or revoked agent token».
• Paso 5: las llamadas se deniegan mientras el almacén no está accesible (nunca se permiten por defecto) y se reanudan cuando vuelve.
• Auditoría: agent.cert.revoked y las llamadas denegadas.

Aprobada: T3 − T1 ≤ 30 s y comportamiento de fallo cerrado. No demuestra: la interrupción de una llamada a herramienta ya en curso (una llamada a conector en ejecución termina o agota su propio presupuesto, perCallBudget.maxWallMs).

4Profundidad de conectores: un proceso real de extremo a extremo, no un logotipo en una página

Afirmación bajo prueba. Los conectores que necesita soportan las operaciones reales, la autenticación y el manejo de errores que su proceso exige.

Preparación

Elija un proceso real con dos de sus sistemas (por ejemplo «nuevo proveedor en SAP → aprobación → registro en ServiceNow», o correo M365 → extracción → SharePoint). Use credenciales de prueba de su lado.

Pasos

1. Automations → Diseñar flujo → construya el proceso con los conectores de la plataforma: disparador, lectura, un paso de aprobación, una escritura. Use Probar paso en cada uno.
2. Ejecútelo una vez de extremo a extremo con datos válidos. Apruebe en Approvals.
3. Ejecútelo con datos inválidos (falta un campo obligatorio en la escritura).
4. Ejecútelo con las credenciales del sistema destino revocadas de su lado.
5. Repita el paso 2 mientras el destino está temporalmente inaccesible (bloquéelo en el cortafuegos un minuto), luego desbloquee.
6. Activity & Results → abra cada ejecución.

Observables

• Paso 2: la escritura aparece en el sistema destino; la ejecución muestra la entrada y la salida de cada paso; la aprobación muestra quién decidió y cuándo.
• Paso 3: la ejecución falla en el paso de escritura con el mensaje de validación del destino (no un error genérico); no se escribió nada parcial.
• Paso 4: el conector falla con un error de autenticación; la plataforma no reintentó a ciegas; la credencial queda marcada en Connectivity.
• Paso 5: el paso reintenta y termina cuando el destino vuelve; el detalle de la ejecución muestra los reintentos.
• Auditoría: eventos run.completed / run.failed; las filas connector.* nombran el host, nunca la carga.

Aprobada: los cinco. No demuestra: la semántica transaccional dentro de su sistema destino; verifique la lógica de compensación en el diseño de su propio proceso.

5Conocimiento y RAG: citas, permisos, documentos escaneados

Afirmación bajo prueba. Las respuestas citan los pasajes de los que proceden; un usuario solo ve lo que su asiento puede ver; los PDF escaneados son legibles cuando hay un modelo de visión configurado.

Preparación

1. Dos espacios, pov-hr y pov-ops; suba 10 documentos reales a cada uno, incluidos al menos dos PDF escaneados y dos documentos que se contradigan (una política antigua y una nueva).
2. El asiento Knowledge Worker es miembro solo de pov-ops.

Pasos

1. Como admin en pov-hr: haga una pregunta que solo responda el PDF escaneado.
2. Haga una pregunta que los dos documentos contradictorios respondan de forma distinta.
3. Como Knowledge Worker, haga la pregunta de pov-hr desde pov-ops, e intente abrir directamente el conjunto de conocimiento de pov-hr (/knowledge?workspace=pov-hr).
4. Borre un documento; vuelva a hacer su pregunta.
5. Admin → Governance → Registro de actividades de tratamiento (art. 30) → exportar.

Observables

• Paso 1: una respuesta con cita al archivo escaneado y la página; la cita abre el pasaje. (Si no hay modelo de visión configurado, la subida lo dice de inmediato: «Parece un documento escaneado. Extraer su texto necesita un modelo de visión…», con honestidad, en lugar de un índice silenciosamente vacío.)
• Paso 2: la respuesta muestra ambas fuentes con fechas y dice que difieren, o cita la más nueva y nombra la antigua; no las mezcla en una única afirmación segura.
• Paso 3: ninguna respuesta con contenido de pov-hr; la URL directa se rechaza (403 en la API, un estado vacío honesto en la interfaz).
• Paso 4: la respuesta ya no cita el documento borrado; la auditoría muestra knowledge.delete.
• Paso 5: la exportación lista los conjuntos de conocimiento como actividades de tratamiento con sus categorías de datos.

Aprobada: los cinco. No demuestra: la calidad de recuperación sobre su corpus a escala; pruébelo sobre un conjunto representativo de 1.000 documentos antes de decidir.

6Plataforma de extensiones: construya un paquete de departamento y llévelo por todo su ciclo de vida

Afirmación bajo prueba. La personalización de un departamento es un paquete firmado de datos: se instala, se activa con parámetros, se actualiza, se revierte y se retira limpiamente, y un paquete firmado con una clave desconocida se rechaza.

Preparación

Node 20 en un portátil; la CLI tools/aancer-pack del paquete de la versión; el capítulo Crear un paquete de la guía del cliente. Un espacio pov-dept.

Pasos

1. aancer-pack keygen --out dept.key. Escriba un manifest.json con un dataset, un modelo de negocio, un panel con un KPI y un gráfico que emita un filtro cruzado, un hook sobre dataset.rows.published, un tema (sus colores), una tarjeta de inicio. Fírmelo: aancer-pack sign manifest.json content/ -o dept-1.0.0.ancpack --key dept.key.
2. Platform Settings → Extensions → Importar paquete antes de añadir su clave.
3. Añada dept.pub en Trust keys; importe de nuevo; Configurar y activar, vinculando pov-dept.
4. Importe 50 filas al dataset por CSV; abra el panel; pulse una barra.
5. Cambie el título del gráfico, suba a 1.1.0, firme, importe, active. Después Revertir a 1.0.0.
6. Retire el paquete.
7. Modifique un byte dentro de un .ancpack firmado (por ejemplo edite content/theme.json en el zip) e impórtelo.

Observables

• Paso 2: rechazado, PACK_SIGNER_UNKNOWN; nada almacenado.
• Paso 3: «Bundle verified», elementos listados con cualquier aviso de contraste; tras la activación cada elemento está Active, el panel aparece en la navegación, el tema se aplica, la tarjeta de inicio se muestra, el hook indica managed by pack.
• Paso 4: el panel muestra sus filas; el clic filtra el KPI y aparece un chip; las entregas del hook muestran una entrega para la importación CSV (si su flujo manejador está publicado con un disparador Event; si no, el hook muestra handler paused, también correcto).
• Paso 5: el título nuevo tras la actualización; el antiguo tras la reversión; ambas versiones listadas.
• Paso 6: panel, tarjeta, tema y hook desaparecen; las filas de los datasets se conservan para auditoría; vuelve la marca estándar.
• Paso 7: rechazado con un error de discrepancia de hash.
• Auditoría: extension.pack.imported|activated|rolled_back|retired, fallos de firma como denegaciones.

Aprobada: los siete. No demuestra: la calidad de paquetes de terceros; demuestra el límite de la plataforma.

7Fallo y recuperación: tumbe cosas en mitad de la ejecución

Afirmación bajo prueba. Las ejecuciones, las aprobaciones y el libro de auditoría sobreviven al fallo de componentes; los reintentos están acotados; el libro permanece intacto y detecta manipulaciones.

Preparación

Instalación Docker (Helm: use kubectl delete pod de forma equivalente). Un flujo con tres pasos y una aprobación en medio (sirve el de la prueba 4). Un hook de la prueba 6.

Pasos

1. Inicie el flujo; mientras se ejecuta el paso 1: docker restart <automation-runner>.
2. Inícielo de nuevo; mientras espera aprobación: docker restart <gateway>; después apruebe.
3. Importe un CSV que dispare el hook; inmediatamente docker stop <postgres> durante 60 s; arránquelo.
4. Integridad del libro: GET $GW/admin/compliance/audit-chain/verify → anote ok:true. Después, como superusuario de la base de datos, intente UPDATE audit_events SET action='x' WHERE id=(SELECT id FROM audit_events LIMIT 1); y TRUNCATE audit_events;.
5. Si tiene acceso directo a la base de datos y quiere ver la propia detección de manipulación: desactive el trigger, modifique la carga de una fila, reactívelo y vuelva a llamar al punto de verificación.
6. GET $GW/metrics (con el token de métricas) y /health.

Observables

• Paso 1: la ejecución termina failed con un error honesto o se completa cuando el runner vuelve, nunca una media ejecución silenciosa; el detalle dice cuál.
• Paso 2: la aprobación sigue pendiente tras el reinicio; aprobar reanuda la ejecución y termina con el mismo id.
• Paso 3: la entrega del hook se reintenta cuando la base de datos vuelve (espera de 30 s, 120 s, 480 s) y se entrega una vez; aancer_event_outbox_pending en /metrics sube y vuelve a 0; ninguna ejecución duplicada.
• Paso 4: la base de datos rechaza ambas sentencias («audit_events is append-only»); verify sigue informando ok:true.
• Paso 5: verify informa ok:false, brokenAt:<row>; la cadena detecta el cambio.
• Paso 6: /health 200; /metrics lista los indicadores de la pasarela y del outbox.

Aprobada: los seis. No demuestra: alta disponibilidad bajo carga sostenida; eso es un ejercicio de dimensionamiento con los sidecars Enterprise.

8Salida: lléveselo todo

Afirmación bajo prueba. Un cliente puede irse con sus datos, sus automatizaciones y la propiedad intelectual de sus extensiones, y puede mantener una versión instalada funcionando sin el proveedor.

Pasos

1. Datasets: Exportar CSV en cada dataset (GET $GW/datasets/<id>/export.csv).
2. Paneles: Exportar como paquete en cada panel publicado, un .ancpack firmado con el panel, los widgets, los modelos y los esquemas de dataset.
3. Flujos: Designer → Exportar JSON de cada flujo (e Importar JSON en una segunda instalación para probar el viaje de ida y vuelta).
4. Cumplimiento: Governance → Exportar el registro de auditoría, el registro del art. 30 y el informe DIFC Reg. 10 (/compliance-log/export, /compliance/gdpr-art30/export, /compliance/difc-reg10/export).
5. Los datos propios de un usuario: Admin → Users → Exportación de acceso (art. 15).
6. Paquetes de extensión: conserve sus archivos .ancpack firmados y su clave privada; la plataforma nunca guarda la clave.
7. Versión congelada: en el host air gap de la prueba 1B, desconéctelo de todo durante una semana; inicie sesión a diario.

Observables

• Los pasos 1 a 5 producen archivos completos que puede abrir fuera de AANCER (CSV, JSON, zip firmado); la segunda instalación importa los flujos y los ejecuta.
• Paso 7: la instalación sigue funcionando; la licencia, un token firmado sin conexión y sin llamadas a casa, no caduca por la desconexión (solo en su propia fecha de caducidad, que puede leer en Platform Settings → Licence).

Aprobada: todo. No demuestra, y lo decimos con claridad: hoy no existe un único botón «exportar toda la instalación»; la salida es la suma de las exportaciones por objeto anteriores más una copia de seguridad de la base de datos, y el sidecar de Backup es un componente Enterprise. El depósito de código fuente es una cuestión contractual, no una función del producto.