Когда строить AI in-house, а когда покупать готовое решение?
Строить in-house — когда AI-функция является долговременным конкурентным отличием, когда данные настолько чувствительны что не могут покидать ваш контур, или когда коробочные системы не дают нужной latency, throughput или integration. Покупать — когда возможность generic (transcription, generic chat, document OCR), когда time-to-value важнее контроля, или когда модели меняются быстрее чем команда успевает. Большинство enterprise-программ заканчиваются гибридом: покупают foundation models, строят orchestration, retrieval, governance и integration слои.
Чем отличается RAG от fine-tuning и когда что использовать?
Generic LLM подходит когда задача open-domain и свежесть внутренних данных не важна. Fine-tuning подходит для consistent task-specific поведения на масштабе при наличии сотен-тысяч высококачественных примеров. RAG подходит когда ответы должны быть grounded в вашем корпусе документов, когда документы часто меняются, или когда нужна source attribution для compliance. В enterprise-практике RAG — default старт; fine-tuning добавляется позже для узких задач где accuracy RAG выходит на плато.
Что входит в AI-стратегию, отличающую её от технологического roadmap?
Технологический roadmap перечисляет что и когда будет построено. AI-стратегия отвечает на четыре предшествующих вопроса: какие решения в бизнесе должен информировать AI, каков допустимый профиль риска для каждого класса решений, какие данные доступны и под какими ограничениями, какие изменения в operating model и governance нужны чтобы абсорбировать AI-outputs в существующие workflow. Без ответов на это roadmap — просто список демо.
Как AI-внедрение пересекается с требованиями 152-ФЗ?
Три критические точки. Первое — локализация: персональные данные граждан РФ должны обрабатываться в инфраструктуре на территории России (ст. 18 152-ФЗ). Это означает что foreign LLM API (OpenAI, Anthropic, Google) для обработки ПДн запрещены без on-prem развёртывания. Второе — согласие: ст. 9 требует явного информированного согласия на обработку ПДн в AI-системах с указанием цели. Третье — журналирование: ФСТЭК-приказ № 21 требует логирования операций с ПДн, включая prompts и model outputs. Архитектура AI должна это учитывать с первого спринта, а не дописываться потом.
Чек-лист 152-ФЗ (20 контролей, 5 минут) →
Что такое импортозамещение AI и какие есть альтернативы OpenAI?
Импортозамещение AI означает замену зарубежных foundation models на open-source модели развёрнутые on-prem или в российском cloud. Практические альтернативы: GigaChat (Сбер) для русскоязычных задач, YandexGPT для интеграций с Яндекс-экосистемой, open-source Llama/Mistral/Qwen на собственной инфраструктуре. Для embedding и vector search: BGE-M3, multilingual-e5, локальные FAISS/Qdrant. Качество для типичных enterprise-задач (RAG, классификация, summarization) сопоставимо с GPT-4 при правильной архитектуре. Latency и стоимость на масштабе обычно лучше у локальной инфраструктуры.
On-prem vs cloud для AI-систем: когда что выбирать?
On-prem обязателен когда ПДн граждан РФ обрабатываются AI (152-ФЗ), когда требования регулятора запрещают вывод данных за периметр (банковский сектор, ГИС), или когда модель кастомная и не должна покидать контур. Cloud (российский) подходит для не-ПДн задач, для пилотов, для систем с переменной нагрузкой. Гибрид — практичный default: критические pipelines on-prem, аналитика и тренировка в cloud с санитайзингом. Foreign cloud (AWS/Azure/GCP) для российских ПДн — компликейтед даже с локальными регионами, требует юридического review.
Что обязательно нужно знать про data residency и GDPR при AI?
Если AI обрабатывает данные граждан EU — GDPR применяется независимо от того где находится ваша компания. Ключевые точки: статья 6 (lawful basis для обработки), статья 13 (информирование субъекта что данные пойдут в AI), статья 22 (право на human review automated decisions). Для cross-border data flow в US нужен EU-US Data Privacy Framework (с 2023) или Standard Contractual Clauses. Запись AI-решений в audit log — обязательна для high-risk систем. EU AI Act (вступает 2025-2026) добавляет obligations для high-risk categories: human oversight, transparency, post-market monitoring.
Как измеряется зрелость AI governance?
Зрелость измеряется по пяти измерениям: inventory (знаете ли вы каждую AI-систему в production), risk classification (классифицирована ли каждая система по impact и регуляторной экспозиции), controls (документированы и enforced ли контроли модели, данных, промптов), monitoring (отслеживаются ли drift, hallucination, incident rate), accountability (есть ли назван owner на каждую систему и escalation path). Если на любой вопрос ответ "нет" для production-системы — это пробел требующий немедленного closure.
Какой минимальный governance baseline до production-развёртывания AI?
Шесть контролей покрывают минимум: (1) задокументированный use case и intended user, (2) назначенный accountable owner, (3) data lineage record покрывающий training, retrieval и prompt sources, (4) протестированный rollback или disable механизм, (5) логирование inputs, outputs и решений, (6) incident-response процедура с определёнными severity levels. Всё что сверх — желательно; ниже — система не должна быть в production.
Какие риски LLM наиболее частые в production регулируемых индустрий?
В порядке частоты в реальных incident reports: утечка данных через prompts и embeddings, hallucinated ответы выдаваемые за authoritative, prompt injection из untrusted document content, unauthorized actions когда LLM получает tool access, silent drift в model behavior через vendor updates. Каждое требует специфического control'а, а не одного generic mitigation. Для финансов и медицины добавляются model bias и reproducibility issues — каждый ответ должен быть deterministic при том же input.
Как контролировать галлюцинации в production AI-ассистентах?
Галлюцинации нельзя устранить, но можно constrain'ить. Эффективные контроли в порядке impact: grounding каждого ответа в retrieved sources через RAG, требование source citations в response schema, rejection или escalation low-confidence ответов, narrowing assistant scope так чтобы out-of-domain вопросы шли на fallback, добавление verification step (rule-based или second-model) для high-stakes outputs. Temperature tuning и prompt engineering помогают marginally; architectural changes — structurally.
За какое время AI-проект окупается в enterprise?
Зависит от класса use case. Internal automation (document processing, ticket routing, summarization) — payback 6-12 месяцев при правильном scoping. Customer-facing assistants (support chat, sales qualification) — 12-18 месяцев, если измеряется reduction in handle time и first-contact-resolution. Decision-support (medical, financial, legal) — 18-36 месяцев, потому что значительная часть ROI от reduction в ошибках, что проявляется на длинном горизонте. Если pilot не показал measurable signal за 90 дней — обычно проблема в use case или data, не в модели.
Сколько стоит enterprise AI-внедрение и из чего складывается стоимость?
Honest enterprise pilot — от 2 до 6 млн руб. за 8-12 недель. Это покрывает: discovery + data audit (15%), prototype + integration (35%), eval framework + governance baseline (20%), production deployment + handover (30%). Production scaling после pilot — от 5 до 20 млн руб в год, доминируется не моделями а инженерией: data pipelines, monitoring, integration с существующими системами, ongoing eval. Foundation model costs обычно 10-25% TCO; остальное — людские часы и инфраструктура. Стоимость линейная по числу use cases, не по объёму данных.
Legacy ROI Calculator — посчитать модернизацию →
Как выбрать векторную базу данных для RAG?
Три варианта в enterprise. PostgreSQL + pgvector — default если у вас уже Postgres; покрывает до 10-50М векторов без проблем, ACID транзакции, без отдельного operational overhead. Qdrant / Weaviate / Milvus — специализированные vector DBs, нужны при 100М+ векторов или сложных hybrid queries (sparse + dense). Pinecone — managed cloud, удобно для пилотов, но не подходит для российских ПДн. Выбор делает разница на масштабе 50М+ векторов; ниже — pgvector обычно достаточно. Главное в RAG не сама vector DB, а chunking strategy и embedding model.
Когда нужен AI-архитектор, а когда хватит ML-инженеров?
ML-инженеры строят и оптимизируют модели — обучение, инференс, monitoring. AI-архитектор отвечает на вопросы которые ML-инженеры не могут: как AI вписывается в существующую системную ландшафт, какие data contracts с upstream-системами, какой governance layer, как обрабатывать failure modes на системном уровне, какая integration strategy. Архитектор нужен на старте программы (определение архитектуры, технических standardов) и на масштабе (когда систем больше 3-5 и появляются cross-cutting concerns). Маленькая команда из 2-3 AI engineers без архитектора работает; программа enterprise-AI на 10+ систем без архитектора создаёт legacy за 18 месяцев.
Не нашли свой вопрос?
Запишитесь на 30 минут с архитектором — обсудим вашу конкретную ситуацию без обязательств.
📅 Записаться на Calendly