Una respuesta de IA puede parecer precisa y, aun así, ser inadecuada para operar sobre un sistema. Que clasifique una solicitud como urgente, sugiera completar un campo o recomiende iniciar un flujo no significa que tenga autorización, contexto suficiente ni que cumpla las reglas de negocio. El riesgo aparece cuando se transforma una sugerencia textual o estructurada en una orden ejecutable sin barreras independientes.
Para validar salidas estructuradas de IA en PHP, conviene tratar el modelo como un componente que prepara propuestas, no como una autoridad que modifica registros, asigna responsables, envía comunicaciones o inicia procesos. La aplicación conserva la decisión, aplica sus propias reglas y registra por qué una propuesta se aceptó, se corrigió o se rechazó.
Una salida plausible no es una instrucción válida
Los modelos pueden devolver JSON correcto desde el punto de vista sintáctico y, pese a ello, incluir una prioridad inexistente, un identificador que no corresponde al cliente, una fecha imposible o una acción que el usuario no puede solicitar. También pueden completar datos no presentes en la entrada, interpretar mal una ambigüedad o seguir un formato antiguo tras un cambio de contrato.
El límite operativo debe ser explícito: la IA puede proponer una acción y explicar los datos que ha usado; el sistema decide si esa propuesta pasa a ser un borrador, requiere revisión o puede ejecutarse bajo condiciones muy acotadas. Esta separación protege tanto la integridad de los datos como la responsabilidad de la decisión.
Un buen punto de partida es clasificar cada acción por impacto:
- Bajo impacto: etiquetar un borrador, sugerir categoría o extraer campos no críticos.
- Impacto medio: crear una tarea pendiente, proponer un responsable o preparar una respuesta para revisión.
- Alto impacto: cambiar estados contractuales, asignar trabajo irreversible, modificar importes, borrar datos, comunicar externamente o activar procesos sensibles.
La autonomía admisible no depende de que la IA tenga una alta confianza declarada. Depende de la reversibilidad, del coste de un error, de la calidad verificable de los datos y de la existencia de controles fuera del modelo.
Definir un contrato de propuesta antes de integrar el modelo
El contrato de salida define qué puede proponer el componente de IA y qué queda fuera de su alcance. Debe ser pequeño, tipado y versionado. En vez de pedir “decide qué hacer con esta solicitud”, especifique una lista cerrada de acciones y los campos necesarios para cada una.
{
"version": "1",
"action": "create_task_draft",
"category": "billing",
"priority": "normal",
"summary": "Revisar discrepancia en factura",
"sourceReferences": ["message:123"],
"confidence": 0.82
}La lista de acciones debe utilizar valores controlados, por ejemplo create_task_draft, request_more_information o no_action. No conviene aceptar nombres de métodos, consultas, fragmentos de código, destinatarios libres ni instrucciones del tipo “actualiza el pedido”. La aplicación traduce una acción permitida a una operación interna concreta.
Campos, estados y evidencia
Además de tipos y valores permitidos, el contrato debe indicar qué campos son obligatorios, qué combinaciones son incompatibles y qué evidencia debe aportar la propuesta. Una categoría puede ser válida, pero requerir al menos una referencia al mensaje o documento de origen. La confianza, si se recoge, es un dato auxiliar para ordenar revisiones; no sustituye una validación.
Versionar el esquema permite rechazar de forma segura salidas de contratos retirados. Si una modificación añade un campo obligatorio o retira una acción, el adaptador debe reconocer la versión y evitar interpretaciones implícitas.
Aplicar cuatro barreras antes de cualquier efecto
La validación debe producirse en capas separadas. Un fallo en una capa no se compensa con una respuesta aparentemente razonable en otra.
- Formato: comprobar que la respuesta se puede decodificar, que respeta el esquema esperado, que no contiene campos críticos inesperados y que cada valor tiene el tipo correcto. Un JSON inválido, una enumeración desconocida o un campo obligatorio ausente se rechazan.
- Dominio: verificar reglas propias de la aplicación. Por ejemplo, que la categoría exista, que la prioridad sea aplicable al tipo de solicitud, que la cuenta referida esté activa y que la referencia de origen pertenezca al contexto procesado.
- Autorización: comprobar qué puede hacer el actor que inició el flujo y qué permisos exige la operación. La IA no hereda privilegios ilimitados ni decide el alcance de acceso. El servidor aplica la identidad, el tenant y las políticas vigentes.
- Condiciones operativas: revisar concurrencia, estados actuales, límites, dependencias e idempotencia. Una propuesta válida puede no poder ejecutarse si el caso ya fue cerrado, otro proceso cambió el registro o se superó un umbral de carga.
La validación semántica debe consultar fuentes de verdad internas. No basta con que el modelo devuelva un identificador bien formado: el repositorio o servicio de dominio debe verificar su existencia, pertenencia y estado. Evite que la respuesta del modelo transporte datos de autorización que la aplicación pueda resolver por sí misma.
Arquitectura PHP: propuesta, decisión y ejecución separadas
Una arquitectura mantenible separa responsabilidades. El adaptador de IA prepara la petición, aplica límites de tamaño y obtiene una salida; no escribe en la base de datos de negocio. Un DTO representa la propuesta ya parseada. El validador de dominio transforma esa propuesta en una decisión con errores explícitos. Por último, un ejecutor autorizado aplica sólo decisiones aprobadas.
final class ActionProposal {
public function __construct(
public string $action,
public string $category,
public string $priority,
public array $sourceReferences,
) {}
}
$proposal = $aiAdapter->propose($input);
$validation = $domainValidator->validate($proposal, $context);
if (!$validation->isApproved()) {
$auditLog->recordRejected($proposal, $validation->reasons());
return $validation;
}
return $decisionService->route($validation->approvedProposal(), $context);El servicio de decisión puede crear un borrador, ponerlo en una cola de revisión o solicitar aprobación humana. El ejecutor final debe recibir un objeto de decisión interno, no la respuesta cruda ni el JSON de la IA. Así se evita que una ampliación accidental del contrato se convierta en una nueva capacidad operativa.
Use transacciones para cambios relacionados, claves de idempotencia para reintentos y controles de concurrencia cuando varias personas o procesos puedan actuar sobre el mismo caso. Diferencie también despliegue de activación: el código puede estar desplegado sin exponer el flujo a usuarios reales. Una activación gradual permite observar rechazos, tiempos y correcciones antes de ampliar el alcance.
Elegir revisión humana, automatización limitada o rechazo
La revisión humana es adecuada cuando hay ambigüedad material, datos sensibles, consecuencias externas, excepciones de política o costes altos de corrección. La interfaz de revisión debería mostrar la propuesta, la evidencia de origen permitida, las reglas superadas y los motivos de alerta, sin presentar la recomendación como un hecho.
La automatización limitada puede ser razonable para operaciones reversibles y acotadas: crear un borrador no asignado, aplicar una etiqueta provisional o enrutar una solicitud a una cola general. Debe tener límites de frecuencia, posibilidad de deshacer y supervisión posterior. Si faltan datos, hay conflicto entre reglas o la acción está fuera de la lista permitida, el comportamiento seguro es rechazar o escalar, no improvisar.
Antes de usar IA, evalúe una alternativa determinista. Si las entradas siguen patrones estables, reglas, formularios guiados, listas de selección o un clasificador convencional pueden ser más baratos, auditables y predecibles. Cuando se use IA, defina el caso de uso, un conjunto de evaluación representativo, umbrales operativos, coste por volumen y un modo de degradación si el proveedor falla o excede el tiempo esperado.
Ejemplo: convertir una solicitud en un borrador de tarea
Suponga una solicitud entrante que menciona una discrepancia en una factura. La IA puede proponer la categoría billing, prioridad normal y el resumen de una tarea. El validador comprueba que el mensaje pertenece al tenant actual, que la categoría está habilitada y que no existe ya un caso abierto con la misma referencia. Si todo es correcto, el sistema crea un borrador sin asignar responsable ni modificar el estado de la factura.
Un operador revisa el borrador, confirma o corrige la categoría y decide la asignación conforme a la carga y permisos vigentes. Esta distinción evita que una inferencia plausible sobre un responsable o un importe se convierta en una modificación errónea. Si el contrato exige un número de factura y éste no aparece en el mensaje, la propuesta debe solicitar información adicional, no inventarlo.
Trazabilidad, privacidad y pruebas antes de ampliar el flujo
Registre un identificador de correlación, versión de contrato, huella o referencia de la entrada minimizada, propuesta normalizada, resultados de cada validación, decisión final, actor aprobador cuando exista y motivo de rechazo. El registro debe ser útil para investigar incidencias sin duplicar datos personales o contenido sensible innecesario. Aplique retención, acceso restringido y técnicas de minimización acordes al riesgo del proceso.
Pruebe el flujo con casos representativos y adversos: entradas incompletas, instrucciones contradictorias, valores inventados, referencias de otro tenant, cambios de estado concurrentes, respuestas con formato antiguo, latencia y ausencia del servicio de IA. Los criterios de aceptación deben medir si se bloquean las operaciones no autorizadas, si los borradores son recuperables, si los rechazos son comprensibles y si el sistema mantiene una alternativa funcional ante fallos.
La operación segura no consiste en lograr que el modelo responda siempre. Consiste en asegurar que, cuando responda mal, tarde demasiado o no responda, la aplicación PHP conserve el control y no produzca efectos que no pueda justificar.
