AI-агент в финтехе: как собирать контекст требований и избегать ложной уверенности
В сфере финтех-разработки анализ требований часто занимает львиную долю времени QA-инженеров и бизнес-аналитиков. Использование искусственного интеллекта обещает ускорить этот процесс, однако на практике нейросети демонстрируют склонность к «галлюцинациям» и пропуску критически важных бизнес-правил. Статья раскрывает методологию использования AI-агентов для сбора корпуса требований, определяет границы их безопасности и объясняет, почему отсутствие доступа к одному документу делает чек-лист неполным, даже если он выглядит идеально отформатированным.
# AI-агент для анализа требований в финтехе: собираем контекст и находим проблемы до разработки
Автоматизация тестирования с помощью нейросетей стала популярным трендом, особенно после внедрения инструментов, способных за секунды формировать базы для тестирования. Однако при работе с финансовыми продуктами простота решения часто маскирует сложность контекста. Нейросеть может уверенно сгенерировать чек-лист, но если в нём отсутствует одно бизнес-правило или актуальная ставка процента, продукт станет уязвимым.
От задачи в Jira к полному корпусу требований
Основная задача AI-агента в этом процессе — не придумывать поведение системы, а выполнять повторяемые операции по структурированию информации. Вместо того чтобы писать черновик с нуля, инженер поручает агенту собрать связный набор источников. Результатом работы становится не просто спецификация, а структурированный артефакт, где каждое требование подтверждается найденными источниками.
Процесс трансформации выглядит так: 1. Jira-задача: Точка входа, определяющая границы работы. 2. Контекст: Связанные страницы, вложения и ссылки на внешние документы. 3. Отсев: Определение релевантных материалов от общей документации проекта. 4. Актуальность: Проверка версий файлов на предмет устаревания. 5. Извлечение: Выявление явно сформулированных требований и сохранение цитат. 6. Корпус: Финальный трассируемый набор данных для анализа.
Важно понимать: AI-агент не является генератором спецификаций в привычном понимании. Его роль — систематизатор доказательной базы. Если документ недоступен, агент не должен выдумывать его содержимое, а должен явно пометить факт отсутствия источника в статусе unresolved.
Управление доверием и классификация источников
Одной из ключевых проблем автоматического сбора данных является бесконтрольный «ползание» по ссылкам, что может привести к обработке устаревших или нерелевантных артефактов. Для борьбы с этим вводится классификация источников:
* Required: Источники, обязательные для обработки для формирования корпуса требований. * Optional: Дополнительные материалы, расширяющие контекст. * Out of Scope: Документы, не связанные с текущей задачей и исключённые из анализа.
Агент должен соблюдать строгие правила доступа: если доступ к файлу (например, внутренней кредитной политике) ограничен, он не может обойти эти ограничения. Невозможность получения данных фиксируется как ограничение доказательной базы.
Пример работы с доступом
В реальном случае агент может столкнуться с таким сообщением:
*Т одного лимита. source: credit-policy-v7 status: not_retrieved reason: restricted_access impact: Credit eligibility rules cannot be fully verified against the available evidence.*
Это означает, что агент не может использовать этот документ как источник истины. Любые выводы, сделанные на основе его содержимого, будут считаться спекулятивными.
Финансовые калькуляции: таблицы против текста
Сложность финтех-проектов часто кроется в расчётных формулах: процентные ставки, полная стоимость кредита (ПСК), комиссии, графики платежей, условия досрочного погашения и правила округления. Эти правила редко фиксируются в текстовых описаниях, а живут в таблицах Excel или формулах.
Агент способен работать с такими данными, если: 1. Файл явно относится к задаче и его версия определена. 2. Формулы доступны для чтения (без размытия или скрытых условий). 3. Документ не содержит запрещённых персональных данных.
Типичная проблема: Агент может зафиксировать правило из таблицы:
*Ежемесячный платёж округляется до двух знаков после запятой по математическим правилам. source: key: attachment:loan-calculation-v3.xlsx location: "Sheet: Calculation Rules > Row 18" quote: Monthly payment: ROUND(result, 2)*
При этом агент не должен объявать эту формулу соответствующей законодательству, а лишь констатировать её наличие в источнике. Если в Jira указан один порядок расчёта, а в Excel — другой, агент выявляет конфликт, не выдумывая решения.
Обработка противоречий и недоступных данных
Главная ценность подхода — прозрачность. AI-агент не пытается скрыть ошибки, а фиксирует их:
* Разные лимиты: Jira указывает кредит до 1 000 000 ₽, а политика — до 500 000 ₽. Агент сохраняет оба правила и указывает, что последнее ограничение зависит от сегмента клиента. * Разные ставки: В задаче — 14,9%, в таблице — 15,2%. Агент фиксирует расхождение, которое может стоить дорого в продакшене. * Недоступная политика: Если Jira ссылается на политику, которой у агента нет доступа, правила принятия решения считаются не полностью извлечёнными. Это обязательно отражается в GAP-листе.
Как это влияет на QA-чек-лист
Качество финального тестового покрытия напрямую зависит от качества собранного корпуса. Если агент пропустил важный раздел кредитной политики или не получил файл с формулами, следующий промпт (который формирует чек-лист) не сможет учесть эти нюансы.
Выводы о статусе корпуса должны быть явными:
* corpus_status: retrieval_complete: true — все возможные файлы обработаны. * extraction_complete: true — извлечение данных завершено. * unresolved_sources: 1 — зафиксировано один источник, к которому нет доступа.
Если агент пропустил требование, чек-лист будет неполным. Риски таких ошибок покрываются на уровне внедрения: контрольными точками, проверкой артефактов и обязательным ревью.
Почему это важно именно в финтехе
Ошибка в ставке, лимите или порядке округления в финтехе может быть значительно дороже обычного дефекта интерфейса. Она влияет на финансовый результат и доверие клиентов.
Именно поэтому подход, при котором: 1. Агенты работают только с авторизированными источниками. 2. Фиксируются все противоречия и недоступные данные. 3. Сохраняются версии документов и исключаются чувствительные данные.
...становится критически важным.
--- Теги: qa, тестирование, анализ требований, ai-агенты, llm, промт-инжиниринг, финтех, jira, confluence, codex
Хабы: Блог компании СВОЙ Тех, Тестирование IT-систем, Искусственный интеллект, Анализ и проектирование систем, Atlassian
--- *Статья опубликована на платформе CВОЙ Тех. Читайте также: [Информация], [Устройство сайта], [Для авторов], [Для компаний].*
О компании: * СВОЙ Тех: Компания, работающая в сфере IT-разработки и тестирования систем. * Дата основания: 2012. * Численность: 1 001–5 000 человек. * Сайт: svoi.ru
© 2006–2026, Habr. Все права защищены.