Operar no dia a dia: atualizar, monitorar, responder

Nesta aula

O custo real da IA local é gente. Esta aula é sobre o que essa gente faz.

Os guias que eu cito desde a aula 1 são unânimes: operar uma IA local exige de meia a uma pessoa dedicada para atualizar modelos, monitorar e responder a incidentes. Numa empresa pequena, isso não vira um cargo novo; vira parte do papel de alguém, com nome, substituto e tempo reservado na agenda. Nesta aula eu descrevo o que essa pessoa faz na semana, no mês e no trimestre, e como responder quando algo dá errado, porque vai dar. No fim, você monta a rotina semanal da sua operação.

• Ao final, você vai saber atualizar modelos e programas sem apostar a operação num download.
• Vai monitorar os sinais que importam e responder a incidentes com método.
• Vai sair com um entregável: a rotina semanal de operação, com responsável, substituto e checklist.

Quem cuida

A primeira decisão da operação é um nome. Não "a TI", não "a equipe": uma pessoa, e uma segunda que sabe fazer o básico quando a primeira está de férias. Se a sua empresa não tem quem possa assumir isso, a decisão honesta é não operar IA local, ou contratar quem opere. A aula 1 já dizia: sem esse nome, o curso te ensina a decidir não fazer.

O que a pessoa responsável faz

• Mantém o ambiente atualizado (modelos, Ollama, interface, sistema), com teste antes de cada mudança.
• Olha os sinais toda semana e age antes de a equipe reclamar.
• Recebe e trata incidentes, registra e comunica.
• Administra contas: cria, desativa no dia da saída, revisa permissões.
• Cuida das coleções com os donos dos documentos (aula 8).
• Mantém a política (aula 11) e o desenho do ambiente (aula 10) em dia.
• Faz e testa backups.

Quanto tempo isso leva depende do tamanho da operação. Para uma equipe de dez pessoas com duas coleções e uma integração, a rotina cabe em algumas horas por semana, com picos quando sai modelo novo ou acontece incidente. Reserve o tempo na agenda; rotina que "faz quando der" não acontece.

Atualizar sem quebrar

Três coisas se atualizam: os modelos, os programas (Ollama e interface) e o sistema operacional. Cada uma tem um risco diferente.

Modelos

Sai modelo novo todo mês, e a tentação de trocar é grande. A regra: versão nova é candidata, não vencedora. O caminho é o da aula 6:

1. Baixe a nova versão com ollama pull, mantendo a atual instalada. As duas convivem no disco; ollama list mostra ambas.
2. Rode a bateria de testes na nova, com a mesma rubrica, e compare com o registro da atual.
3. Se a nova for melhor de forma clara, troque o modelo padrão na interface e nas integrações. Se não for, fique com a atual e registre por quê.
4. Depois de uma ou duas semanas sem problema, remova a antiga com ollama rm para liberar disco.

O outro lado da moeda é a armadilha que os guias apontam: tratar modelo antigo como seguro. Modelo não "estraga", mas o mundo muda: surgem modelos que inventam menos, entendem melhor o português e cabem na mesma memória. Por isso a rodada trimestral da bateria existe mesmo quando ninguém reclamou.

Programas

Ollama e interface recebem atualizações frequentes, com correções de segurança. Atualize em janela combinada (fora do horário de pico), com backup feito antes e um teste rápido depois: abrir a interface, fazer uma pergunta, consultar uma coleção, rodar uma chamada de API. Leia as notas da versão; de vez em quando muda algo que afeta a sua configuração.

Sistema operacional

A máquina da IA é um servidor. Patches de segurança do sistema entram no mesmo ritmo dos outros computadores da empresa, e a máquina reinicia em horário combinado. Máquina sem patch numa rede interna é a porta que a aula 10 mandou fechar.

Monitorar: os sinais que importam

Monitorar não é olhar gráfico bonito. É uma planilha semanal com meia dúzia de linhas, preenchida pela pessoa responsável, e um olhar treinado para o que mudou.

A amostra de dez conversas é o sinal mais valioso e o mais negligenciado. Dez conversas por semana, escolhidas ao acaso, conferidas contra a fonte com a rubrica da aula 6. Se a taxa de invenção subir, você descobre antes do cliente. Lembre da política: a amostra é lida com justificativa e dentro do prazo de retenção, não para vigiar quem perguntou.

Responder a incidentes

Incidente é qualquer coisa que a operação não previa: máquina caiu, resposta errada chegou ao cliente, alguém acessou o que não devia, documento sensível entrou na coleção geral por engano, suspeita de vazamento. O método é o mesmo para todos, em quatro passos.

1. Conter. Parar o que está causando dano: pausar a integração, desativar a conta, tirar o documento da coleção, desligar a máquina da rede se for o caso. Antes de entender a causa.
2. Registrar. Data, hora, o que aconteceu, quem percebeu, o que foi feito. No mesmo dia, num registro que sobreviva (não numa conversa de mensagem).
3. Comunicar. A quem a política diz (aula 11). Se envolver dado pessoal, quem responde pela LGPD decide se a ANPD e os titulares precisam ser avisados; isso tem prazo e não é decisão da pessoa responsável pela operação sozinha.
4. Corrigir e aprender. Investigar a causa, corrigir, e escrever o que mudou na rotina para não repetir. Um incidente sem mudança de rotina é um incidente que vai voltar.

Você pode usar um assistente de nuvem para montar o modelo de registro de incidente, porque ele não tem dado real:

A rotina: semana, mês, trimestre

A rotina cabe numa página, com caixas para marcar. Ela é o que transforma "a gente cuida" em "está cuidado": quando alguém perguntar, você mostra a planilha das últimas semanas.