Как я построил guardrails, которые не дали моему AI-агенту пойти вразнос

В сфере искусственного интеллекта произошло заметное событие. xiji 4 минуты назад Как я построил guardrails, которые не дали моему AI-агенту пойти вразнос Средний 8 мин 0 DevOps * Информационная безопасность * Python * Туториал Из песочницы На третий день мой агент слил email одного клиента в переписку с другим клиентом. Это была не гипотетическая история из доклада на конференции. Это был мой код, в проде, делающий то, что я никогда не тестировал.

Я собрал support-агента на LangGraph и GPT-4o. Он умел искать по базе знаний, подтягивать детали аккаунта и готовить ответы. В staging он работал прекрасно.

Технические детали

В проде ему понадобилось ровно 72 часа, чтобы вытащить PII одного пользователя в разговор с другим. Причина оказалась до неловкого простой: модель включила сырой контекст из базы данных прямо в ответ, и ничто в моём пайплайне это не проверяло. Постфактум фикс был очевиден.

Фреймворки для AI-агентов дают вам оркестрацию, вызов инструментов и память. Они не дают вам безопасность. Почему ваш фреймворк не включает guardrailsLangChain, CrewAI, LangGraph, Agents SDK от OpenAI.

Ни один из них не идёт из коробки с валидацией входа, фильтрацией выхода или контролем расходов. Они исходят из того, что вы добавите это сами. Большинство команд так и не добавляют.

Отраслевые последствия

Почему это важно — объясняет простая арифметика. При точности 90% на шаг, агентный workflow из 5 шагов успешен в 59% случаев. Workflow из 10 шагов падает до 35%.

На 20 шагах вы на уровне 12%. Каждый незащищённый шаг — это умножение вашей вероятности отказа. Guardrails не чинят точность.

Они ограничивают радиус поражения, когда точность отказывает. Разница между «агент дал неправильный ответ» и «агент дал неправильный ответ, в который попал чей-то номер соцстрахования» — это один output-валидатор. Следующие две недели я строил стек guardrails.

Событие, по словам экспертов, усилит конкуренцию в сфере ИИ.