Como montar um projeto de IA que não perde o contexto da empresa toda semana
Um roteiro para organizar fontes, instruções, decisões e conversas em Projects do ChatGPT ou Claude sem transformar memória em fonte oficial da verdade.
Por Cesar A. Machado · · 3 min
Defina uma finalidade e uma fonte oficial para cada projeto.
Separe instruções permanentes de pedidos temporários.
Registre decisões fora da memória informal do chat.
Teste o projeto com perguntas conhecidas e casos sem resposta.
Um Project não é uma pasta de despejo
Projects no ChatGPT e no Claude mantêm chats, arquivos e instruções ligados a um trabalho. Isso alivia a repetição de contexto, e eu considero esse ganho excelente. O problema começa quando a empresa confunde memória conveniente com fonte oficial. Se eu colocar política antiga, planilha sem data e uma conversa contraditória no mesmo espaço, a IA ganhará mais contexto e menos clareza.
Imagine um Project chamado Comercial. No desenho ruim, ele recebe contratos, propostas, listas de preço e atas sem proprietário nem validade. No desenho bom, ele tem uma finalidade estreita — preparar propostas — e aponta qual tabela define preços, qual documento define termos e onde registrar exceções aprovadas.
As quatro camadas que eu usaria
Camada
Conteúdo
Regra
Finalidade
Entrega e público
Uma frase verificável
Instruções
Tom, formato, limites
Poucas regras permanentes
Fontes
Documentos autorizados
Dono, data e validade
Decisões
Mudanças aprovadas
Registro fora do chat
Eu escreveria instruções que mudam pouco: quem recebe a saída, quais fontes podem ser usadas, como indicar incerteza e o que nunca deve ser executado. Um pedido da semana, como comparar três propostas, fica na conversa. Misturar tudo nas instruções permanentes cria um manual enorme que ninguém consegue revisar.
Para fontes, eu manteria um índice curto com nome, autoridade, responsável e última revisão. Links conectados ajudam a buscar material atualizado, mas permissões continuam valendo. Um arquivo acessível não significa que deveria estar naquele projeto.
Eu testo com respostas que já conheço
Antes de usar o Project numa decisão real, eu faria cinco perguntas com resposta conhecida, duas em que as fontes discordam e uma que não pode ser respondida. O resultado bom cita ou identifica a fonte e admite ausência. O resultado ruim completa a lacuna com uma resposta plausível.
Quando o teste falha, eu corrijo a fonte ou a instrução específica. Não adiciono um parágrafo genérico pedindo para a IA ser cuidadosa. Se o preço veio errado, descubro qual tabela ela usou. Se misturou clientes, separo projetos e permissões. Se inventou uma decisão, exijo referência ao registro aprovado.
Uma vez por mês, eu removeria fontes vencidas, atualizaria o índice e revisaria decisões. Também verificaria se o projeto começou a atender finalidades demais. Um espaço que prepara propostas, responde RH e analisa contratos provavelmente precisa ser dividido.
Planos de maior capacidade tornam essa rotina mais confortável quando há muitos arquivos e conversas. Eles não corrigem ownership. A fonte oficial continua sendo o sistema ou documento que a empresa escolheu, e não a lembrança produzida pelo modelo.
Quando configurar vira trabalho de arquitetura
Eu montaria sozinho um Project pessoal de baixo risco. Procuraria ajuda quando existem dados de clientes, fontes conectadas, vários usuários, regras de retenção ou necessidade de transformar a saída em ação noutro sistema. Nesse ponto, configuração e governança precisam nascer juntas.
Se você quer organizar um Project para uma área real, descreva em https://blog.cesarmachado.com/contato a entrega recorrente, as fontes e quem deve aprovar o resultado. Eu posso desenhar a estrutura, testar os casos difíceis e indicar se Projects bastam ou se a empresa precisa de uma integração.
Os projetos são apresentados pelo problema e pela engenharia envolvida, preservando informações internas. O objetivo é mostrar como decisões de produto, arquitetura e operação se conectam.
Um projeto começa com uma pergunta de negócio, avança por uma primeira versão controlada e só cresce quando os dados mostram que a solução cabe na operação.
{{ item.num }}
{{ item.title }}
{{ item.text }}
LIMITES CLAROS
A confiança também está no que o sistema não promete.
Empresas de 20 a 100 pessoas, com um processo real para melhorar.
O ponto de partida é um processo específico, com responsável, volume e impacto identificáveis. A solução precisa caber na capacidade da equipe, produzir evidência e preservar controle sobre decisões importantes.
→{{ item }}
Tecnologias e camadas
A FERRAMENTA SEGUE O PROCESSO
{{ item }}
SE FIZER SENTIDO
Descreva um processo que você gostaria de entender melhor.
Envie o fluxo atual, o volume aproximado e o principal gargalo. A primeira conversa serve para entender o problema e avaliar o próximo passo mais proporcional.
Ferramentas
Clique em uma ferramenta para abrir. Conteúdo de cada uma a definir.
Kit atual
{{ t.num }}
{{ t.title }}
{{ t.desc }}
{{ t.state }}
Portfólio
Projetos de software e ecossistemas construídos com engenharia de IA. Conteúdo de cada caso a definir.
{{ caseCount }}
Projetos
capa do projeto{{ p.num }}
{{ p.kind }} · {{ p.year }}
{{ p.title }}
{{ p.desc }}
{{ tg.label }}
ABRIR CASO
{{ detail.num }}{{ detail.kind }}
{{ detail.title }}
{{ detail.desc }}
{{ m.k }}
{{ m.v }}
imagem principal do caso
{{ bl.title }}
{{ bl.hint }}
Briefing
3 PASSOS · CERCA DE 1 MINUTO
Toque nas opções que descrevem seu projeto. Só o último passo pede digitação.
Briefing recebido
Obrigado. Retorno pelo e-mail informado com as próximas perguntas.
