Использование ИИ для распутывания 10 000 бразильских прав собственности: технический кейс-стади

Контекст проекта и проблема

Бразильская компания по недвижимости унаследовала примерно 10 000 прав собственности в более чем 10 муниципалитетах с десятилетиями плохого управления. Данные включают сотни незарегистрированных "контрактов в ящике" (неформальные продажи, никогда не подававшиеся на регистрацию), дублирующиеся продажи одних и тех же объектов, мошеннические контракты, поддельные доверенности, незаконные захваты и примерно 500 активных судебных процессов, включая иски о приобретательной давности, принудительное отчуждение, выселения, споры о двойных продажах и 2 коллективных иска. Физический архив документов частично хранится в полиции в рамках старого расследования.

Технический подход

Команда (6 юристов + 3 оператора) решила не строить инфраструктуру заранее, выбрав вместо этого подход "сначала исследование" с помощью ИИ. План включает пять шагов:

• Шаг 1 - Физическое сканирование: Документы организованы по муниципалитетам, сканируются партиями с соглашением об именовании: [муниципалитет]_[тип-документа]_[последовательность] с использованием сканера документов с автоподатчиком (ADF).
• Шаг 2 - OCR: Рассматриваются Google Document AI, Mistral OCR 3, AWS Textract или другие инструменты. Команда просит отзывов об инструментах, специально протестированных на деградировавших документах латиноамериканских реестров.
• Шаг 3 - Исследование: Подача вывода OCR напрямую в инструменты ИИ с большими контекстными окнами для открытого анализа перед настройкой базы данных. Использование Gemini 3.1 Pro (в NotebookLM или другом интерфейсе) для широкого пакетного анализа с запросами типа "какие участки связаны более чем с одним покупателем?", "отметьте контракты с нелогичными датами", "определите кластеры подозрительных имён или активности" и "помогите нам увидеть проблемы и решения для того, что мы не замечаем". Параллельный запуск Claude Projects для аналогичного анализа.
• Шаг 4 - Очистка и стандартизация данных: Нормализация извлечённых сырых данных перед вставкой в базу данных. Приведение названий муниципалитетов, написанных разными способами ("B. Vista", "Bela Vista de GO", "Bela V. Goiás") к канонической форме, стандартизация CPF (бразильских идентификационных номеров) с пунктуацией и без, исправление несоответствующих описаний статуса участков на перечисляемые категории и нечёткое сопоставление имён покупателей с вариантами написания. Инструменты: Python + rapidfuzz для нечёткого сопоставления, Claude API для нормализации свободных текстовых полей в категории. Команда спрашивает, достаточно ли нечёткого сопоставления + нормализации LLM для 10 000 записей с десятилетиями несоответствий или им нужна более строгая разрешающая идентификация сущностей (например, Dedupe.io).
• Шаг 5 - База данных: Выбранный стек: Supabase (PostgreSQL + pgvector) с NocoDB сверху. Были оценены три варианта: Airtable (самый простой для начала, но ограниченный в масштабе), прямой PostgreSQL (максимальный контроль, но медленная итерация) и Supabase + NocoDB (выбран как компромиссный вариант).

Цель - получить реальную консолидированную картину за 30-60 дней, избежав предыдущих неудачных попыток организации.