AI-отчётность: как собирать данные без выдуманных выводов

Почему AI-отчётности нужна граница истины

AI-ассистент может собрать понятный черновик из многих записей, но не делает исходные данные полными, свежими и сопоставимыми. Особенно опасен уверенный текст, который превращает пропуск в причинное объяснение, смешивает периоды или незаметно меняет определение метрики. Отчёт становится рабочим артефактом только тогда, когда каждое существенное утверждение можно провести к разрешённому источнику, его версии и правилу расчёта.

Широкая задача принадлежит странице услуги AI-автоматизации. Этот материал отвечает на более узкий вопрос: как спроектировать контролируемый reporting pipeline, который готовит читаемый черновик, но сохраняет lineage источников, результаты проверок и human decision boundary. Он не обещает точный прогноз, подтверждённый ROI или автономные управленческие решения.

Начните с одного регулярного отчёта для одной роли. Зафиксируйте решение, которому он помогает, период, словарь метрик, owners источников и допустимую задержку. Если у KPI нет согласованного определения или owner не может объяснить источник, сначала нужно исправить data governance, а не добавлять модель.

Архитектура REPORT-8

REPORT-8 разделяет сбор, расчёт и генерацию narrative. Модель получает ограниченный evidence packet; она не ходит свободно по production-системам и не придумывает причину изменения.

1. Receive. Сохранить run ID, запрошенный период, аудиторию, версию шаблона и immutable source receipt.
2. Collect. Забрать только утверждённые datasets через scoped connectors; записать source ID, время выгрузки, schema version, permission scope и freshness status.
3. Normalize. Привести даты, валюты, entity ID и названия метрик по явным правилам; сохранить rejected rows и mapping warnings.
4. Calculate. Получить deterministic aggregates из versioned formulas. За totals и comparison отвечает calculation artifact, а не ответ модели.
5. Validate. Проверить completeness, соответствие периодов, reconciliation, threshold rules и неожиданную variance. Неуспешная проверка становится exception, а не скрытой сноской.
6. Explain. Передать модели validated metric table, разрешённые evidence snippets и uncertainty flags. Потребовать отдельно помечать observation, hypothesis и evidence ID.
7. Review. Named owner принимает, правит или отклоняет черновик с существенными решениями, внешними claims или неразрешёнными exceptions.
8. Publish and reconcile. Доставить утверждённый отчёт в разрешённый destination, прочитать его обратно, сохранить rendered version и открыть recovery при неясной доставке.

approved sources -> deterministic metrics -> validation gates -> bounded AI narrative -> owner review -> verified report

Расчёт намеренно остаётся вне generative text. Ассистент может сказать, что выручка ниже сопоставимого периода только после того, как data contract определил и revenue, и period comparison. Он не должен превращать correlation в cause без source-backed evidence.

Минимальный evidence contract

У строки метрики должно быть больше, чем число: metric ID, definition version, period, dimensions, source references, calculation version, freshness result и validation state. Черновик отчёта связывает claim с этими ID. Например, безопасный output разделяет подтверждённое наблюдение и открытый вопрос:

{
  "metric": "qualified_leads",
  "period": "2026-07",
  "value": 84,
  "comparison": { "period": "2026-06", "value": 96, "change": -12 },
  "evidence": ["crm_export_2026-08-01", "metric_definition_v4"],
  "validation": "passed",
  "narrative": "Квалифицированных лидов стало меньше, чем в предыдущем периоде.",
  "hypothesis": "Для объяснения причины в этом evidence set недостаточно данных."
}

Это не универсальная схема отчёта, а граница: workflow сообщает, что подтверждено данными, сохраняет unknowns и направляет следующий вопрос owner. Definitions, access rights и retention должны соответствовать утверждённой политике организации.

Failure modes, которые нужно спроектировать

Самые опасные ошибки отчётности выглядят правдоподобно. Connector может вернуть частичную выгрузку после API timeout; dashboard — сравнить календарный месяц с fiscal period; переименование CRM stage — изменить funnel без смены query; поздняя корректировка — сделать вчерашний отчёт устаревшим. Затем модель напишет убедительное объяснение дефекта, которого не видит.

Нужны явные маршруты:

• Missing или stale source: заблокировать затронутую метрику, показать source status и закрепить recovery owner.
• Schema или definition drift: остановить calculation до review mapping и версии метрики.
• Reconciliation mismatch: сохранить оба totals, evidence и tolerance rule; не выбирать более красивое число.
• Unsupported explanation: пометить как вопрос или убрать, а не выдавать за анализ.
• Duplicate или ambiguous delivery: использовать idempotency key, read-back destination и recovery из сохранённого report artifact.
• Permission leakage: фильтровать evidence packet до generation; аудитория отчёта не получает автоматически доступ ко всем rows и documents.

Ни error budget, ни одна «accuracy» не заменяют эти controls. Практичные signals: coverage пройденных validation checks, freshness exceptions, reconciliation mismatches, claim-to-evidence coverage, review corrections и verified delivery coverage.

Тестирование перед production-отчётом

Соберите representative historical или synthetic fixtures: нормальное закрытие периода, пустой source, запоздалая выгрузка, duplicate event, изменённое KPI definition, timezone boundary, conversion валюты, late correction, reconciliation mismatch и читателя без доступа к одному источнику. Тестируйте formulas отдельно от narrative prompts, затем собранный report и recovery delivery.

Минимальный release gate можно сделать inspectable:

require(run.id && period.closed && template.version && sources.every(hasReceipt));
require(metrics.every(isFormulaVersioned) && checks.every(isPassedOrOwned));
publish = review.authorized && report.claims.every(hasEvidenceOrQuestion) && destination.readBack;

Для первого pilot оставьте output advisory: weekly operations summary, finance-preparation pack или sales-quality review. Manual reporting route должен остаться доступным. Расширять workflow имеет смысл только когда команда может провести claim к источнику, исправить defect, восстановить delivery и назвать owner каждого exception.

От черновика к support для решения

AI может сократить труд на сбор отчёта, но не становится source of truth. Production unit — это evidence-backed report: source receipts, deterministic calculations, visible validation results, bounded narrative, owner review и verified destination. Для architecture review можно опереться на гайд по AI-автоматизации, посмотреть широкий локальный scope на странице AI-специалиста в Армении, изучить кейсы или описать один process slice в брифе.