Как использовать принципы Клода и Кодекса в вашей компании, не нарушая принципов корпоративного управления.

Что вы найдете в этой статье:

• Почему индивидуальное использование ИИ само по себе не приводит к улучшению государственного управления.
• Три уровня, организующие работу: где она производится, где она фиксируется и где она выполняется.
• Как распределить использование ресурсов между командами, не блокируя доступ никому из них.
• Что можно и нельзя включать в разговор, и кто утверждает то, что из него получится.
• Понятие как источник корпоративной истины: что регистрировать и как это назвать.
• Рекомендации по разработке с использованием Claude Code и Codex: инструкции по работе с репозиторием, права доступа, проверка и публикация.
• Одностраничный контрольный список для самооценки компании.
• Где Bytebio Вступает в игру: организация использования или руководство командами.

Практически в каждой компании ИИ проникает окольным путем. Кто-то открывает аккаунт, решает задачу, на выполнение которой обычно уходит полдня, за двадцать минут, сообщает об этом коллеге, и вскоре половина команды уже использует его. Производительность реальна. Чего не существует, так это остального: никто не знает, какие данные были вставлены в какие разговоры, качественный анализ хранится в личных историях, а решение, принятое с помощью ИИ, не оставляет следов, кроме фразы в WhatsApp.

Запрет ИИ не решает проблему, потому что запрет лишь скрывает его использование. Выпуск всего подряд тоже не сработает. Путь вперед заключается в разделении того, что ИИ делает хорошо, а именно производства, от того, что компания должна защищать, а именно того, что она приняла за истину, и в том, чтобы каждой вещи было отведено свое место.

В этой статье предлагается простая схема решения этой проблемы. В примерах используются системы Claude и Codex, как в повседневной работе, так и в разработке, но предложенная схема применима к любому ассистенту.

Проблема не в искусственном интеллекте, а в исчезающих рабочих местах.

Когда каждый человек использует ИИ самостоятельно, повторяются три вещи.

• Знания часто оказываются в ловушке разговора. Успешный анализ, утвержденный текст, критерии, согласованные командой в десяти сообщениях: все это существует только в истории переписки человека, который говорил. Когда этот человек уходит в отпуск или покидает компанию, работа уходит вместе с ним.
• Данные вводятся без каких-либо критериев. Никто не решал, что можно обсуждать. Каждый руководствуется здравым смыслом, и то, что для одного человека является здравым смыслом, не соответствует политике компании.
• Акции остались без владельца. Когда ассистент начинает отправлять сообщения, редактировать записи или изменять код, вопрос меняется с того, что написал ассистент, на то, кто это разрешил.

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

Три уровня, каждый из которых выполняет свою роль.

Используемая нами схема разделяет работу на три слоя, каждый из которых имеет своё место и свои правила.

Принцип работы проекта можно кратко сформулировать так: главное — это результат обсуждения. Когда результат превращается в решение, документ или код, он перемещается на уровень записи или выполнения с указанием автора, даты и источника. Обсуждение можно удалить без потери данных, поскольку ценная информация уже находится в месте, контролируемом компанией.

Это имеет положительное практическое последствие: компания становится менее зависимой от конкретного инструмента. Если команда завтра сменит ассистента или будет использовать двух одновременно, знания останутся на том же месте. Что касается необходимости существования записи до начала использования ИИ, стоит почитать о том, как документировать способы снижения зависимости.

Организуйте использование между командами.

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

Контекст определяется областью, а не человеком. Каждая команда (продажи, обслуживание клиентов, финансы, разработка) получает стандартный контекст: чем занимается компания, используемая лексика, тон общения, неизменные правила. Без этого каждый человек объясняет все заново, и каждый получает разный результат на один и тот же вопрос. Контекст записывается один раз, сохраняется в Notion и вставляется или подключается в любом месте, где это позволяет инструмент.

Роли четко определены, и их немного. Для начала достаточно четырех: кто использует данные; кто поддерживает контекст для каждой команды; кто утверждает коннекторы и доступ, как правило, это ИТ-отдел или отдел безопасности; и кто отвечает за персональные данные, как правило, это юридический отдел или сотрудник по защите данных.

Что является личным, а что принадлежит компании. Разработка и анализ документов бесплатны. Всё, что становится результатом работы клиента, официальным документом или решением, становится собственностью компании и заносится в архив.

Библиотека успешно выполненных запросов. Успешно выполненный запрос — это ценный ресурс. Когда кто-то создает хороший аналитический скрипт или хорошую модель ответа, он попадает на страницу Notion с указанием владельца и даты, вместо того чтобы оставаться в памяти одного человека.

Это корпоративный аккаунт, а не личный. Административные функции различаются в зависимости от тарифного плана. На странице тарифного плана Claude Enterprise , например, перечислены единый вход (SSO), управление доступом пользователей, управление доступом на основе ролей, журналы аудита и средства контроля хранения данных. Перед выбором проверьте, что включает в себя тарифный план, который ваша компания собирается заключить, как для Claude, так и для Codex, в официальной документации каждого из них. Этот список ответит на вопрос, который задаст ИТ-отдел: кто к чему получил доступ и когда.

Данные: что поступает, что не поступает, что выходит

Большинство рисков можно охватить тремя правилами.

1. Классифицируйте данные по трем уровням: открытые (могут использоваться в любом разговоре), внутренние (доступны только в рамках корпоративного аккаунта) и ограниченные (конфиденциальные персональные данные, информация о здоровье, финансовые данные и учетные данные любого рода). Ограниченные данные либо недоступны, либо доступны только в среде, одобренной компанией. Учетные данные, пароли и ключи доступа никогда не доступны ни на одном уровне. Правовая основа и цель обработки персональных данных в соответствии с Общим законом Бразилии о защите персональных данных (LGPD) определяются юридическим отделом, а классификация данных определяет применимость этого решения в повседневной работе.

2. Подключайтесь с минимальным количеством разрешений. Когда помощник подключается к системе (CRM, календарь, диск, база данных), следует начинать с доступа только для чтения, разрешать запись только там, где это необходимо, и периодически проверять, кто и к чему имеет доступ. Один коннектор на одну цель, с ответственным владельцем.

3. Люди утверждают действия, имеющие внешние последствия. Отправка сообщения, публикация, удаление, оплата, изменение информации о клиенте: помощник предлагает, человек подтверждает. Когда автоматизация становится повторяющейся и объемной, как, например, обслуживание клиента оператором, контроль смещается от утверждения каждого действия к полному ведению журнала, версионированию и утверждению изменений. Это разница между проверкой каждого ответа и проверкой системы, которая реагирует.

Общую структуру управления ИИ и его основные составляющие см. в статье «Управление ИИ: успех или неудача».

Понятие как источник истины

Второй слой работает только при наличии формы. Мы используем и рекомендуем концепцию, но важен дизайн: уникальное место с правилами именования, принадлежности и действительности.

Что записывается.

• Решения: Что было решено, почему, кем, когда и какие альтернативы были отброшены. Эта страница ответит через шесть месяцев на вопрос: «Почему мы поступили именно так?».
• Итоговые документы: Текущая версия политики, предложения, руководства или плана действий. Черновики следует размещать в «Клоде» или «Кодексе»; всё важное остаётся здесь.
• Анализ: Анализ, не содержащий даты и источника, устаревает без предупреждения, что требует уточнения вопроса, указания исходных данных, даты и заключения.
• Соответствующие беседы: База данных содержит по одной строке на каждое сообщение, в результате которого был достигнут результат, с указанием конкретного заголовка, источника, краткого описания с возможностью поиска, статуса и ссылки для повторного открытия. Сохраняется не всё, а только то, что оказало влияние.

Минимальные требования к оформлению. Заголовок, указывающий на тему, а не «Разговор 12». Источник: инструмент и дата. Владелец: один человек, а не команда. Статус: черновик, пересмотренный, текущий или замененный. Дата пересмотра, чтобы страница указывала, когда она больше не считается достоверной.

Достоверность и конфликт. Когда на двух страницах говорится разное, команде необходимо знать, какая из них является достоверной. Письменное правило приоритета (например, инструкция руководства предшествует опубликованной политике, которая, в свою очередь, предшествует разрабатываемому предложению) разрешает большинство случаев до того, как они станут предметом спора.

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

Само по себе Bytebio Вот как это работает. Разговоры, в результате которых что-то происходит, становятся записью в базе данных Notion с заголовком, источником, кратким описанием, статусом и ссылкой для повторного открытия, в то время как контент, относящийся к организации, поступает со страниц Notion, рассматриваемых как источники, причем в случае конфликта приоритет отдается именно им.

Разработка с использованием кодов и кодексов Клода.

В процессе разработки управление имеет преимущество: культура версионирования, проверки и публикации уже существует. Лучшая практика — внедрить эту культуру в работу помощника, а не обходить её стороной.

1. Инструкции находятся в репозитории. Клод Код читает файл. CLAUDE.md в начале каждой сессии, и Кодекс считывает AGENTS.mdОба файла хранятся в репозитории, версионируются вместе с кодом и распространяются через Git, поэтому инструкция применяется ко всей команде и меняется с каждой редакцией, как и все остальное. Здесь размещаются команды сборки и тестирования, соглашения, то, что никогда не следует делать, и где принимаются решения. Документация Claude Code рекомендует использовать короткие, лаконичные файлы (менее 200 строк): "run npm test «Перед фиксацией» работает лучше, чем «проверьте свои изменения». В Codex файлы считываются из корневого каталога репозитория в рабочий каталог, при этом приоритет отдается ближайшим файлам, а размер набора по умолчанию ограничен 32 КиБ.

Эффективная структура, которая служит обеим целям:

# Instruções do projeto

## Comandos
- Testes: npm test
- Build: npm run build

## Regras
- Nunca publicar em produção sem autorização de uma pessoa.
- Segredos ficam fora do repositório.
- Decisões em docs/DECISOES.md, estado atual em docs/ESTADO.md.

Если команда использует оба инструмента, достаточно одного файла: в последних версиях Claude Code считывает файл. AGENTS.md когда нет CLAUDE.mdи принимает его импорт с помощью строки. @AGENTS.md внутри CLAUDE.md.

2. Инструкция по эксплуатации, настройка обеспечивает... Именно это различие чаще всего упускается из виду. Согласно самим документам, Кодекс Клода рассматривает... CLAUDE.md В контексте, а не как навязанная конфигурация. То, что необходимо гарантировать, например, предотвращение действия или доступа к файлу, включается в контекст. управляемые настройкиОрганизация распространяет эти инструкции на машины, и клиент применяет их независимо от решений помощника, или же использует «перехватчики», которые запускаются в фиксированное время. У Codex есть своя версия этого, с песочницей и подтверждением со стороны агентов. Общее правило: то, что «никогда не может произойти», — это не фраза в файле инструкций, а блок.

3. Минимальные права доступа и изолированная среда. Ассистент начинает с чтения и запрашивает подтверждение любых внесенных изменений. Секрет остается вне репозитория и вне контекста разговора. Работа выполняется в отдельной ветке, а не в основной.

4. Процесс доставки такой же, как и для людей. Ветка, запрос на слияние, проверка, автоматизированные тесты, слияние. Ассистент открывает запрос на слияние; он не публикует его напрямую в основную ветку. Публикация в продакшн требует авторизации от пользователя в этот момент и предварительной проверки того, что сборка и тесты пройдены.

5. Память проекта хранится в репозитории. Каждая сессия начинается без запоминания предыдущей. Короткий файл состояния, содержащий информацию о том, что мы делаем, где остановились и что будет дальше, обновляется в конце каждого шага, что позволяет любой сессии, независимо от пользователя или инструмента, возобновить работу с нужного места. Claude Code также сохраняет автоматические заметки, но они остаются на компьютере пользователя; вся необходимая информация хранится в репозитории.

6. Для одновременной работы нескольких сессий требуется постановка в очередь. При работе нескольких сессий над одной и той же системой риск перераспределяется. Мы видели, как это происходило: две сессии публиковали данные из одной и той же системы, и одна из них непреднамеренно отменяла исправления другой. Решение небольшое и недорогое: панель или скрипт, отображающие открытые изменения, порядок интеграции, текущие изменения и правило интеграции по одному изменению за раз.

7. Приложение, созданное с помощью ИИ, — это не система. Приложение, разработанное за один день на платформе типа Base44, подтверждает эту идею, но оно становится инструментом компании только тогда, когда получает права доступа на основе профилей, поддержку больших объемов данных, интеграцию и владельца. В настоящее время в компании этот путь находится на стадии кодирования.

Контрольный список на одной странице

Люди и счета

1. Эти счета принадлежат компании, у них назначен ответственный администратор, и они не являются личными картами.
2. У каждой команды есть свой владелец контекста по умолчанию.
3. Есть человек, который утверждает разъемы и точки доступа.

Данные

4. Три уровня доступа (открытый, внутренний, закрытый) прописаны, и команда о них осведомлена.
5. Учетные данные, пароли и ключи никогда не упоминаются в разговоре.
6. Каждый коннектор имеет владельца и минимально возможные права доступа.
7. Любое действие, имеющее внешние последствия, требует одобрения какого-либо лица.

регистрация

8. Решения, окончательные документы и анализы отправляются в Notion вместе с информацией об источнике, авторе, статусе и дате внесения изменений.
9. Существует письменное правило приоритета в случаях, когда два источника расходятся.
10. Помощник составляет черновик информации; кто-то другой придает ей статус действующей.

Развитие

11. В каждом репозитории есть свой краткий и лаконичный файл с инструкциями.
12. Недопустимо то, что заложено в конфигурации, а не только в инструкциях.
13. Изменения происходят посредством ветвления, проверки и тестирования; для публикации требуется разрешение.
14. Имеется файл состояния, а если сессий несколько, то и очередь.

когда начать

Не начинайте со всей компании. Выберите команду и алгоритм действий, в которых ИИ уже используется, и разработайте весь процесс именно для них.

1. Укажите место регистрации, правила именования, владельца и статус. Половины страницы вполне достаточно.
2. Опишите правила использования на одной странице: Три уровня данных, что требует утверждения и кто его утверждает.
3. В процессе разработки напишите файл инструкций для репозитория и перенесите информацию, исключающую возможность ошибок, в файл конфигурации.
4. Используйте его, а затем пересмотрите. Действия команды, направленные на обход правила, показывают, где она допустила ошибку. Нужно корректировать правило, а не команду.

Как только разработка одной команды оказывается успешной, остальные копируют её, внося корректировки на основе собственной работы.

Такие как Bytebio может помочь

A Bytebio Это инженерная компания. Ribeirão PretoС 2009 года компания внедряет ИИ, автоматизацию и CRM-системы в предприятиях, чья прибыль зависит от операционной деятельности, и несет ответственность за то, что она создает. Интеллектуальные операцииМы помогаем организовать использование Claude и Codex: проектирование слоев, структура записей в Notion, правила обработки данных, а также, на этапе разработки, файл инструкций, права доступа и порядок доставки. Мы также консультируем команды, чтобы практика продолжала работать и после завершения консультаций.

Если ИИ уже используется в вашей компании, но его результаты пока ограничиваются личными разговорами, поговорить с BytebioМы начинаем с обсуждения того, как сегодня организована работа, и откровенно говорим, с чего стоит начать организацию.