Ответ ИИ может выглядеть точным и всё же быть непригодным для работы с системой. То, что он классифицирует запрос как срочный, предлагает заполнить поле или рекомендует запустить поток, не означает, что у него есть разрешение, достаточный контекст или что он соблюдает бизнес-правила. Риск возникает, когда текстовое или структурированное предложение преобразуется в исполняемую команду без независимых барьеров.
Чтобы проверять структурированные ответы ИИ в PHP, модель следует рассматривать как компонент, подготавливающий предложения, а не как субъект, наделённый полномочиями изменять записи, назначать ответственных, отправлять сообщения или запускать процессы. Приложение сохраняет за собой принятие решения, применяет собственные правила и фиксирует, почему предложение было принято, исправлено или отклонено.
Правдоподобный ответ — не действительная инструкция
Модели могут вернуть синтаксически корректный JSON и при этом включить несуществующий приоритет, идентификатор, не соответствующий клиенту, невозможную дату или действие, которое пользователь не может запрашивать. Они также могут заполнить данные, отсутствующие во входных данных, неверно истолковать неоднозначность или использовать старый формат после изменения контракта.
Операционная граница должна быть явной: ИИ может предлагать действие и объяснять, какие данные он использовал; система решает, станет ли это предложение черновиком, потребует проверки или может быть выполнено в строго ограниченных условиях. Такое разделение защищает как целостность данных, так и ответственность за решение.
Хорошей отправной точкой будет классификация каждого действия по воздействию:
- Низкое воздействие: пометить черновик, предложить категорию или извлечь некритичные поля.
- Среднее воздействие: создать незавершённую задачу, предложить ответственного или подготовить ответ для проверки.
- Высокое воздействие: изменять договорные статусы, назначать необратимую работу, менять суммы, удалять данные, осуществлять внешние коммуникации или активировать чувствительные процессы.
Допустимая автономность не зависит от того, заявляет ли ИИ высокую уверенность. Она зависит от обратимости, стоимости ошибки, проверяемого качества данных и наличия контролей вне модели.
Определите контракт предложения до интеграции модели
Контракт вывода определяет, что может предлагать компонент ИИ и что находится вне его области действия. Он должен быть небольшим, типизированным и версионируемым. Вместо запроса «реши, что делать с этим обращением» укажите закрытый список действий и поля, необходимые для каждого из них.
{
"version": "1",
"action": "create_task_draft",
"category": "billing",
"priority": "normal",
"summary": "Проверить расхождение в счёте",
"sourceReferences": ["message:123"],
"confidence": 0.82
}Список действий должен использовать контролируемые значения, например create_task_draft, request_more_information или no_action. Не следует принимать имена методов, запросы, фрагменты кода, произвольных получателей или инструкции вида «обнови заказ». Приложение преобразует разрешённое действие в конкретную внутреннюю операцию.
Поля, состояния и доказательства
Помимо типов и разрешённых значений, контракт должен указывать, какие поля обязательны, какие комбинации несовместимы и какие доказательства должно предоставить предложение. Категория может быть допустимой, но требовать как минимум одной ссылки на исходное сообщение или документ. Уверенность, если она собирается, — вспомогательные данные для упорядочивания проверок; она не заменяет валидацию.
Версионирование схемы позволяет безопасно отклонять ответы из выведенных из эксплуатации контрактов. Если изменение добавляет обязательное поле или удаляет действие, адаптер должен распознать версию и не допускать неявных интерпретаций.
Применяйте четыре барьера до любого эффекта
Валидация должна происходить в отдельных слоях. Сбой на одном уровне не компенсируется внешне разумным ответом на другом.
- Формат: проверить, что ответ можно декодировать, что он соответствует ожидаемой схеме, не содержит неожиданных критичных полей и что каждое значение имеет правильный тип. Недопустимый JSON, неизвестное значение перечисления или отсутствующее обязательное поле отклоняются.
- Домен: проверить собственные правила приложения. Например, что категория существует, приоритет применим к типу обращения, указанная учётная запись активна, а ссылка на источник принадлежит обрабатываемому контексту.
- Авторизация: проверить, что может делать субъект, запустивший поток, и какие разрешения требуются для операции. ИИ не наследует неограниченные привилегии и не определяет область доступа. Сервер использует действующие идентификационные данные, tenant и политики.
- Операционные условия: проверить конкурентный доступ, текущие состояния, лимиты, зависимости и идемпотентность. Допустимое предложение может быть невозможно выполнить, если случай уже закрыт, другой процесс изменил запись или превышен порог нагрузки.
Семантическая валидация должна обращаться к внутренним источникам истины. Недостаточно, чтобы модель вернула корректно сформированный идентификатор: репозиторий или доменный сервис должен проверить его существование, принадлежность и состояние. Не позволяйте ответу модели передавать данные авторизации, которые приложение может разрешить самостоятельно.
Архитектура PHP: предложение, решение и выполнение разделены
Поддерживаемая архитектура разделяет обязанности. Адаптер ИИ подготавливает запрос, применяет ограничения размера и получает ответ; он не записывает данные в бизнес-базу данных. DTO представляет уже распарсенное предложение. Доменный валидатор преобразует это предложение в решение с явными ошибками. Наконец, авторизованный исполнитель применяет только одобренные решения.
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);Сервис принятия решений может создать черновик, поместить его в очередь проверки или запросить одобрение человека. Конечный исполнитель должен получать внутренний объект решения, а не необработанный ответ или JSON ИИ. Это предотвращает превращение случайного расширения контракта в новую операционную возможность.
Используйте транзакции для связанных изменений, ключи идемпотентности для повторных попыток и контроль конкурентного доступа, когда несколько людей или процессов могут действовать по одному случаю. Также различайте развёртывание и активацию: код может быть развёрнут без предоставления потока реальным пользователям. Постепенная активация позволяет наблюдать отклонения, время обработки и исправления до расширения охвата.
Выбирайте проверку человеком, ограниченную автоматизацию или отклонение
Проверка человеком уместна, когда есть существенная неоднозначность, чувствительные данные, внешние последствия, исключения из политик или высокая стоимость исправления. Интерфейс проверки должен показывать предложение, разрешённые исходные доказательства, пройденные правила и причины предупреждений, не представляя рекомендацию как факт.
Ограниченная автоматизация может быть разумной для обратимых и ограниченных операций: создать неназначенный черновик, присвоить предварительную метку или направить запрос в общую очередь. Она должна иметь ограничения частоты, возможность отмены и последующий надзор. Если данных не хватает, правила конфликтуют или действие находится вне разрешённого списка, безопасное поведение — отклонить или эскалировать, а не импровизировать.
Перед использованием ИИ оцените детерминированную альтернативу. Если входные данные следуют стабильным шаблонам, правила, управляемые формы, списки выбора или традиционный классификатор могут быть дешевле, проверяемее и предсказуемее. При использовании ИИ определите сценарий применения, репрезентативный набор для оценки, операционные пороги, стоимость на объём и режим деградации, если у провайдера произойдёт сбой или время ответа превысит ожидаемое.
Пример: преобразование обращения в черновик задачи
Предположим, входящее обращение упоминает расхождение в счёте. ИИ может предложить категорию billing, обычный приоритет и краткое описание задачи. Валидатор проверяет, что сообщение принадлежит текущему tenant, категория включена и ещё не существует открытого случая с той же ссылкой. Если всё корректно, система создаёт черновик, не назначая ответственного и не изменяя статус счёта.
Оператор проверяет черновик, подтверждает или исправляет категорию и принимает решение о назначении в соответствии с текущей нагрузкой и разрешениями. Это различие не позволяет правдоподобному выводу об ответственном или сумме превратиться в ошибочное изменение. Если контракт требует номер счёта, а он не указан в сообщении, предложение должно запросить дополнительную информацию, а не выдумывать его.
Трассируемость, конфиденциальность и тестирование до расширения потока
Фиксируйте идентификатор корреляции, версию контракта, отпечаток или ссылку на минимизированные входные данные, нормализованное предложение, результаты каждой проверки, окончательное решение, субъекта, одобрившего решение, если он есть, и причину отклонения. Журнал должен быть полезен для расследования инцидентов, не дублируя без необходимости персональные данные или чувствительное содержимое. Применяйте сроки хранения, ограниченный доступ и методы минимизации, соответствующие риску процесса.
Тестируйте поток на репрезентативных и неблагоприятных сценариях: неполные входные данные, противоречивые инструкции, выдуманные значения, ссылки другого tenant, одновременные изменения состояний, ответы в старом формате, задержки и недоступность сервиса ИИ. Критерии приёмки должны измерять, блокируются ли неавторизованные операции, можно ли восстановить черновики, понятны ли отклонения и сохраняет ли система работоспособную альтернативу при сбоях.
Безопасная эксплуатация заключается не в том, чтобы модель всегда отвечала. Она заключается в том, чтобы при неправильном ответе, слишком долгом ответе или отсутствии ответа приложение PHP сохраняло контроль и не вызывало последствий, которые не может обосновать.
