Предложение по интеграции с AI API должно объяснять, как функция вписывается в ваш рабочий процесс, что происходит, когда поставщик или модель не могут ответить, и как ваша команда контролирует доступ, использование, расходы и журналы. Сравнивайте предложения, запрашивая конкретные детали реализации и тестирования, а не принимая общие обещания вроде «безопасно» или «масштабируемо».
Определите рабочий процесс и поведение при сбоях
Опишите задачу, которую должен выполнять AI, кто её запускает, какую информацию он получает и что ваш продукт делает с результатом. Например, различайте черновик, который проверяет сотрудник, и ответ, который напрямую показывается клиенту. От этого различия зависят этапы утверждения, обработка ошибок и необходимые тесты.
Попросите каждого поставщика описать путь от действия пользователя до результата, включая приложение или серверную часть, поставщика AI, этап извлечения данных, если он есть, и пользовательский интерфейс. Определите, какие входные данные могут содержать персональную, конфиденциальную или коммерчески чувствительную информацию, и согласуйте, что можно отправлять поставщику. Если системе необходимы административный интерфейс или управление ролями, уточните, должны ли они входить в интеграцию или относиться к отдельной разработке панели администратора и серверной части.
В предложении также следует объяснить, что увидят пользователи, если истечёт время ожидания запроса, запрос будет отклонён, вернётся непригодный ответ или отправка окажется невозможной из-за достижения лимита поставщика. Возможные варианты включают понятную возможность повторить попытку, резервный сценарий без AI, сохранение черновика или передачу задачи сотруднику. Подходящий вариант зависит от рабочего процесса; требуйте от поставщика конкретного описания, а не исходите из предположения, что AI всегда выполнит задачу.
Уточните порядок работы с ключами и управление доступом
Запросите письменное описание того, где хранятся учётные данные поставщика, какие компоненты приложения имеют к ним доступ и как обеспечивается их отсутствие в общедоступном клиентском коде, репозиториях исходного кода и обычных журналах. Уточните, как команда будет разделять учётные данные для разработки и рабочей среды, ограничивать доступ кругом необходимых людей и систем, а также заменять ключ в случае его утечки или изменения прав доступа.
Также уточните, кому принадлежат учётные записи: чья учётная запись поставщика используется, кто контролирует оплату и доступ к ней и что происходит с учётными данными при передаче проекта. Не отправляйте действующие ключи в документе с предложением или в обычных проектных сообщениях. Согласуйте безопасный способ их передачи на этапе реализации и попросите поставщика задокументировать процесс, не приводя секретные значения.
Достоверный ответ описывает этапы реализации и передачи проекта, а не просто называет его безопасным. В перечне услуг по интеграции с AI API безопасная работа с ключами указана как один из возможных элементов интеграции; уточните, как это будет реализовано для предлагаемой модели, среды и схемы владения.
Запросите лимиты, контроль расходов и полезные журналы
Запросите средства контроля как на уровне поставщика AI, так и на уровне приложения. Лимиты в учётной записи поставщика могут помочь ограничить общий объём использования или настроить уведомления, а средства контроля в приложении могут ограничивать круг пользователей, способных отправлять запросы, их частоту и размер входных данных. Уточните, какие средства контроля фактически доступны у выбранного поставщика, а какие нужно реализовать в вашей системе.
В оценке расходов должны быть указаны исходные допущения: ожидаемый объём запросов, типичный размер входных и выходных данных, выбранная модель или услуга, повторные попытки и любые другие включённые сборы поставщика. Уточните, что произойдёт при приближении к согласованному порогу использования или его достижении, кто получит уведомления и будет ли система приостанавливать работу, ставить запросы в очередь, переходить к резервному режиму или требовать одобрения администратора для дальнейшего использования. В каждой оценке следует указывать использованные данные о ценах и дату их актуальности; прежде чем принимать решение, проверьте текущие цены напрямую у поставщика.
Журналы помогают диагностировать сбои и расследовать неожиданное использование, однако запись полных запросов и ответов может раскрыть чувствительную информацию. Уточните, какие события и поля записываются, кто может их просматривать, как долго хранятся записи и исключается, маскируется ли содержимое запросов и ответов либо сохраняется только при необходимости. Попросите поставщика разграничить журналы приложения, записи на стороне поставщика и любые панели мониторинга использования или выставления счетов.
| Требование для технического задания | Что должно быть указано в предложении | Как это проверить |
|---|---|---|
| Хранение ключей и доступ | Место хранения, роли доступа, разделение сред, порядок ротации или замены и владение при передаче проекта | Проверьте схему развёртывания и настройки доступа; убедитесь, что ключ отсутствует в клиентском коде, истории репозитория и примерах журналов |
| Лимиты использования и расходов | Применяемые средства контроля поставщика и приложения, поведение при достижении порога, уведомления и допущения, лежащие в основе расчётов расходов | Проведите проверку при согласованном лимите; изучите соответствующие настройки или панель мониторинга и подтвердите ожидаемую реакцию |
| Журналы и обработка данных | Записываемые события и поля, доступ, срок хранения и порядок обработки содержимого запросов и ответов | Отправьте тестовый запрос и проверьте пример записи журнала: в нём должны быть полезные диагностические сведения и не должно быть непреднамеренно раскрытых чувствительных данных |
| Поведение при сбоях | Поведение при истечении времени ожидания, ошибке поставщика, отклонённом запросе, непригодном ответе и достижении лимита | Проверьте согласованные сценарии сбоев и подтвердите результат для пользователя и передачу задачи сотруднику, если она предусмотрена |
| Материалы для тестирования и передачи проекта | Тестовые сценарии, подтверждение приёмки, исходный код и эксплуатационная документация, включённые в результат работ | Изучите результаты тестирования и материалы для передачи проекта до приёмки работ |
Согласуйте тесты и критерии приёмки до сравнения предложений
Преобразуйте требования в проверяемые критерии «пройдено/не пройдено». Включите обычный запрос, отсутствующие или некорректные входные данные, недоступность поставщика, истечение времени ожидания, отклонение запроса поставщиком, непригодный ответ, событие достижения лимита использования и попытку доступа неавторизованного пользователя. Если система должна предусматривать проверку результатов человеком, протестируйте и этот этап утверждения.
Для каждого сценария определите ожидаемый пользовательский опыт, будет ли запрос отправлен повторно, что будет записано и изменится ли какой-либо счётчик расходов или использования. Попросите поставщиков указать, как они будут тестировать интеграцию, какие подтверждающие материалы предоставят и что не входит в объём работ. Избегайте критериев вроде «AI работает хорошо»: задайте формат результата, обязательные поля, порядок обработки неопределённости и случаи, когда результат должен проверить человек.
Сравнивайте предложения, исходя из одного и того же рабочего процесса, средств контроля и критериев приёмки. В предложении с меньшим объёмом работ могут отсутствовать мониторинг, административные средства контроля, сценарии сбоев или документация для передачи проекта, поэтому запросите письменный перечень исключений и допущений. Уточните, входят ли в поставку исходный код, документация, тестирование и поддержка запуска, а также определите текущие задачи по управлению учётной записью поставщика и обслуживанию, за которые будет отвечать ваша команда.
Часто задаваемые вопросы
Следует ли хранить ключ AI API в мобильном приложении или браузере?
Попросите поставщика объяснить архитектуру и способы защиты учётных данных от раскрытия конечным пользователям. Не считайте, что ключ становится конфиденциальным, если его скрыть в приложении или браузере; в предложении должно быть указано, какой доверенный компонент отправляет запросы поставщику и как ограничивается доступ.
Следует ли записывать запросы и ответы AI в журнал?
Не обязательно. Журналы должны помогать устранять неполадки и проверять использование, соответствуя при этом вашим требованиям к обработке данных. Согласуйте, какие поля необходимы, исключается или маскируется ли содержимое, кто может получать доступ к записям и как долго они хранятся. Перед запуском проверьте полученные журналы на репрезентативных данных.
Как справедливо сравнить оценки расходов?
Предоставьте всем поставщикам одинаковые допущения об использовании и попросите показать расчёт, выбранного поставщика или модель, включённые сборы, допущения о повторных попытках и дату, на которую актуальны использованные цены. Рассматривайте результат как оценку, а не гарантию, и уточните актуальные цены и средства контроля учётной записи у поставщика.
Чтобы подготовить техническое задание проекта, укажите задачу AI и путь пользователя, целевое приложение или систему, предпочтительного поставщика, если он известен, ожидаемые показатели использования, типы данных, необходимые лимиты и правила уведомлений, предпочтения по ведению журналов, тестовые сценарии и того, кому будет принадлежать учётная запись поставщика. Добавьте сведения о существующей архитектуре, ролях доступа и требованиях к передаче проекта. Затем обсудите требования, чтобы определить предполагаемый объём работ.