TextCortex: enterprise AI-платформа, которая не тренирует свою модель — значит, вряд ли собирает сырьё для обучения

TextCortex — не безымянный «AI и LLM-краулер», а известная на рынке enterprise-платформа для интеграции ИИ в рабочие процессы компаний: сервис с оценкой 4,9 из 5 при более чем 1500 отзывах, GDPR-совместимой инфраструктурой в ЕС и визуальным конструктором AI-агентов без необходимости писать код. Платформа явно не строит собственную базовую языковую модель — она подключает целый набор сторонних LLM (Claude, GPT, Gemini и другие) от Anthropic, OpenAI, Mistral и Google, позволяя клиентам работать с их же данными и базой знаний через единый интерфейс.

Что вероятнее всего объясняет обход сторонних сайтов

Ключевая функциональность TextCortex, судя по описанию продукта, — не генерация текста «из ниоткуда», а работа поверх собственных данных и знаний конкретного клиента: интеграция с корпоративной базой знаний, автоматизация workflow, создание, например, RFP-агента, который составляет коммерческие предложения на основе документов компании. Логичное продолжение такой модели — возможность подключить внешний источник (конкретный URL или веб-страницу) как часть базы знаний конкретного пользователя или агента, чтобы AI-модель могла ссылаться на актуальную информацию оттуда при генерации ответа. Это тот же паттерн, что уже разбирался для нескольких инструментов в этой серии (Rytr, Outwrite, Klaviyo-подобные сценарии): обращение к конкретной странице происходит по факту действия конкретного пользователя, подключающего источник к своему рабочему процессу, а не ради системного накопления обучающего корпуса для базовой модели, которую компания сама и не разрабатывает.

Параметры бота

Почему исходная классификация «сырьё для AI-пайплайна» неточна

Поскольку TextCortex сама не тренирует базовую языковую модель, а лишь подключает чужие модели поверх данных клиента, версия о системном накоплении контента как обучающего сырья для собственной LLM здесь маловероятна с самого начала — компании попросту незачем строить такой корпус для модели, которую она не разрабатывает. Куда правдоподобнее, что обращения к сайтам — результат того, что кто-то из пользователей платформы указал конкретный URL как источник данных для своего AI-агента или ассистента.

Как проверить эту гипотезу по своим логам

# Базовый поиск
grep -i "textcortex" /var/log/nginx/access.log

# Точечные обращения или системный обход?
grep -i "textcortex" /var/log/nginx/access.log | awk '{print $7}' | sort | uniq -c | sort -rn | head

Единичные, разрозненные обращения к конкретным страницам без глубокого прохода по всему каталогу соответствуют гипотезе о точечном подключении источника пользователем; заметный, регулярный и широкий обход — повод пересмотреть эту версию.

Стоит ли блокировать

• если гипотеза о точечном подключении верна, присутствие бота — нейтральный факт: кто-то из корпоративных пользователей платформы сослался на страницу сайта как на источник данных для своего рабочего процесса;
• если объём запросов заметен и нежелателен независимо от причины — блокировка не несёт последствий для видимости в поисковых системах;
• на позиции в органической выдаче Google, Bing или Яндекса присутствие или отсутствие этого бота не влияет.

Как заблокировать

Стандартный запрет через robots.txt:

User-agent: textcortex
Disallow: /

Поскольку официального подтверждения соблюдения robots.txt для этого агента не найдено, для надёжности запрет стоит продублировать на уровне сервера:

if ($http_user_agent ~* "textcortex") {
    return 403;
}

Если полный запрет избыточен при небольшом точечном объёме, разумная альтернатива — ограничение частоты:

limit_req_zone $binary_remote_addr zone=textcortex:10m rate=10r/m;
location / {
    if ($http_user_agent ~* "textcortex") {
        limit_req zone=textcortex burst=20 nodelay;
    }
}