Alcance, ROE, ética y marco legal

Tipo: Conceptual / operativo · Fase: Pre-engagement

PhiloCorp te habilita una cuenta de prueba y te dice «podés avanzar». Todavía falta una parte: qué agente usa esa cuenta, qué otros servicios puede alcanzar y quién puede detenerlo si una solicitud inicia varias acciones. La cuenta habilita acceso; el RoE define cómo usarlo durante la evaluación.

Las reglas de compromiso (RoE, Rules of Engagement) convierten ese permiso general en acciones concretas, con límites y responsables. El resultado de esta página es un acuerdo escrito que permita decidir qué prueba sigue y cuándo hay que parar.

Alcance específico de IA

Definí explícitamente:

• Qué componentes están en scope: modelo, RAG/KB, agentes y sus tools, servidores MCP, vector stores, model registry, infraestructura.
• Qué categorías RAI se evalúan (ver categorías de riesgo) y cómo se mide el éxito en las que viven en espectro. En particular, qué se evalúa de forma adversarial y qué por revisión funcional.
• Entornos: identificá el laboratorio o staging designado para los cambios reversibles. Las pruebas de esta guía usan datos sintéticos; no requieren acciones destructivas.
• Datos: inventariá el corpus sintético permitido y acordá cómo detener y notificar un acceso accidental a datos personales o secretos, sin copiarlos al reporte.
• Límites operativos: presupuesto de requests, tokens y costo; tasa máxima; blast radius (radio de impacto máximo aceptable por prueba, en acciones, datos y tenants); punto de rollback; y condición de detención por degradación o efecto inesperado.
• Kill switch: para sistemas con acciones autónomas, acordá quién puede frenar al agente, por qué mecanismo, y verificá que el mecanismo existe y se probó antes de empezar. Un agente que no se puede frenar no se puede probar en producción.

Reglas de compromiso (RoE)

• Qué técnicas están permitidas, restringidas o prohibidas. Por ejemplo, una ingesta controlada en la KB de staging puede estar permitida mientras toda modificación de producción queda fuera.
• Ventanas de tiempo, especialmente para pruebas que impactan disponibilidad (DoS/cost harvesting).
• Manejo de payloads: usá objetivos de prueba inocuos, datos sintéticos y evidencia mínima. Toda prueba que cambie estado requiere autorización explícita, rollback probado y limpieza al cierre.
• Contactos de escalamiento si algo se rompe (una acción puede desencadenar otras).
• Stop conditions: detener, notificar y preservar evidencia mínima si se supera el límite de costo, se accede a datos fuera de scope, falla un control crítico o aparece comportamiento no previsto.

Un esqueleto mínimo de RoE para engagement de IA, adaptable por componente:

engagement: PHILO-LAB-001
componentes_en_scope: [modelo, rag_kb, agentes, mcp_servers, vector_store, registry, infra]
categorias_rai_en_scope: [secure_resilient, privacy_enhanced]
tecnicas:
  permitidas: [prompt_injection_con_marcadores, enumeracion_autorizada]
  restringidas: [ingesta_en_staging]
  prohibidas: [poisoning_produccion, exfiltracion_real, denegacion_de_servicio]
limites:
  presupuesto_tokens: <acordado>
  tasa_maxima: <rpm>
  blast_radius: <acciones/datos/tenants maximos por prueba>
  rollback: <mecanismo y responsable>
  kill_switch: <mecanismo, responsable y fecha de prueba>
stop_conditions: [costo_excedido, datos_fuera_de_scope, control_critico_caido,
  comportamiento_no_previsto]
evidencia: minima, sintetica y sanitizada
contactos_escalamiento: [canal acordado]
ventanas: <franjas horarias aprobadas>

Consideraciones legales

El RoE no reemplaza la revisión legal del contrato. Confirmá con la asesoría correspondiente la jurisdicción, el sector y el rol de cada parte, además de retención de evidencia, transferencias, obligaciones de notificación y licencias de modelos y datasets. Esta página orienta ese encuadre; no determina qué norma aplica a un engagement concreto.

Dos ejemplos verificados al 10-sep-2026 muestran por qué la fecha importa:

• Unión Europea. El Reglamento (UE) 2024/1689 (AI Act) tiene aplicación escalonada. El Reglamento (UE) 2026/1744, publicado el 24-jul-2026, modificó sus reglas y calendario. Consultá el texto consolidado y la categoría concreta del sistema antes de fijar una obligación.
• Colorado, EE.UU. SB26-189 reemplazó el marco de SB24-205 y establece obligaciones para ciertas tecnologías de decisión automatizada desde el 1-ene-2027. No es una regla general para cualquier uso de IA ni se traslada automáticamente a otra jurisdicción.

Estos ejemplos explican qué verificar, no certifican cumplimiento. Registrá en el brief la norma, la versión consultada y quién confirmó su aplicabilidad.

• Terceros: si el sistema integra APIs o servidores MCP de terceros, aclará qué está en scope para no atacar infraestructura de un tercero no autorizado.
• Datos generados: la generación de contenido dañino (aunque sea para medir guardrails) debe acordarse; usá objetivos de prueba equivalentes e inocuos en vez de contenido realmente peligroso.

No determinismo y reproducibilidad

Una misma entrada puede producir resultados distintos por muestreo, infraestructura, contexto, memoria o cambios de versión. Guardá la configuración disponible, incluida temperatura y seed si el servicio las expone; no prometas determinismo sólo por fijarlas.

Acordá de antemano cuántas repeticiones entran en el presupuesto. Informá éxitos sobre intentos, condiciones y variación, sin presentar esa proporción como una probabilidad universal. Una sola acción indebida bien documentada puede confirmar una falla, aunque haga falta repetir para caracterizar su frecuencia. Un conjunto sin éxitos tampoco demuestra ausencia de vulnerabilidad.

Cierre y retest

Definí antes de empezar cómo se validarán remediaciones, quién revoca los accesos temporales y cómo se eliminan artefactos de prueba. El retest debe repetir solamente el caso mínimo que confirma el control, sin volver a recolectar datos innecesarios.

Checklist de pre-engagement

• Alcance por componente y por categoría RAI acordado por escrito
• RoE con técnicas permitidas/restringidas/prohibidas y ventanas de tiempo
• Blast radius por prueba y kill switch probado para acciones autónomas
• Manejo de PII, secretos y payloads peligrosos definido
• Marco legal verificado por jurisdicción, contrato y sector, a la fecha del engagement
• Contactos de escalamiento y plan ante efectos autónomos inesperados
• Límites de tasa, costo, impacto, rollback y stop conditions acordados
• Repeticiones, configuración, éxitos/intentos y límites de interpretación acordados
• Retest, revocación de accesos y limpieza de artefactos acordados