IA na prática: 20 respostas diretas

Explicando

Apps desse tipo (o Duet, que mostra seus agentes e projetos no celular, é um exemplo) funcionam bem para quem já tem as ferramentas conectadas por servidores MCP (conectores que deixam o assistente de IA usar outros programas, como e-mail, agenda ou planilha) e quer acompanhar os projetos longe do computador.

O risco é o contrário: abrir o app e encontrar dezessete avisos de coisas que você ainda não fez. Em vez de organizar, isso aumenta o estresse.

A alternativa é abrir de propósito a sessão do assistente em que você quer trabalhar agora, sem que todos os projetos pela metade fiquem chamando sua atenção.

Para guardar

• Se o app ajuda você a cuidar dos projetos fora de casa, continue.
• Se cada notificação vira culpa, prefira abrir uma sessão por vez.
• É preferência de fluxo, não regra.

Para aprofundar no INEMA

Explicando

Com os dois aplicativos abertos, você pede ao Codex que acompanhe o Claude: conferir o que ele produziu, navegar, responder uma pergunta, abrir outra sessão ou destravar algo que parou durante a noite.

O que faz isso funcionar é o contexto que você entrega: o objetivo e quais decisões você tomaria no lugar dele.

Atenção: para agir na tela, o Codex precisa de permissão para controlar o computador (mouse, teclado, janelas). Dê essa permissão só numa máquina e numa conta sem dados sensíveis abertos, e acompanhe as primeiras vezes.

Dá para coordenar os dois também pela linha de comando, mas os apps de desktop já resolvem sem manter mais um sistema.

Para guardar

• Sem API: um agente olha a tela do outro.
• Explique o objetivo e os critérios de decisão.
• Controle do computador é permissão forte: use com cuidado.

Para aprofundar no INEMA

Explicando

Um exemplo: tirar os testes automáticos do GitHub Actions (o serviço do GitHub que roda tarefas na nuvem e cobra pelo tempo) e passar para computadores próprios do escritório. Pelo terminal (com o Warp, por exemplo, que acessa outras máquinas da rede), dá para ver cada pedido que chega e garantir que cada tarefa roda no computador certo.

Numa construção comum não é preciso acompanhar cada linha de código. Basta que o resultado funcione e os testes certos passem.

Ninguém precisa copiar a configuração de ninguém. Cada pessoa vai ter sua combinação de ferramentas; o que importa é que elas conversem entre si.

Para guardar

• Terminal: quando precisa ver cada passo.
• App: quando basta ver o resultado e os testes.
• Ferramentas que conversam valem mais que a interface ‘certa’.

Para aprofundar no INEMA

Explicando

A capacidade atual dos modelos já basta para muito trabalho útil. O ponto de atenção é outro: quem já sabe atacar sistemas passa a fazer isso com mais automação e em escala muito maior.

Ao mesmo tempo, empresas continuam lançando aplicativos que não entendem por completo.

Por isso faz sentido dedicar mais tempo a proteger o que já foi construído, ajudar empresas a enxergar seus riscos e preparar o próprio negócio para um ambiente mais difícil.

Para guardar

• Os modelos de hoje já resolvem muito.
• Ataques automatizados crescem mais rápido que a proteção.
• Proteger o que existe virou prioridade.

Para aprofundar no INEMA

Explicando

Quem só desenvolve já sente a pressão: em sites de freelancer aparecem projetos complexos oferecidos por valores muito baixos. Se a única proposta é “eu construo isso com IA”, você disputa com cada vez mais pessoas e ferramentas.

As empresas continuam precisando de alguém que entenda o que elas querem alcançar, saiba onde vale investir, encontre os problemas e ensine a equipe a usar as ferramentas do jeito certo.

Bons clientes de desenvolvimento ainda existem. Mas a atenção vale mais em consultoria empresarial e treinamento de equipes.

Para guardar

• “Eu construo com IA” sozinho não diferencia.
• Entender o negócio e ensinar a equipe vale mais.
• Desenvolvimento continua, mas como parte do serviço.

Para aprofundar no INEMA

Explicando

Começar com recursos próprios (o chamado bootstrap) mantém o controle na sua mão.

Se precisar de investidor, um critério prático para o prazo: conte quantos meses faltam até a próxima meta que torna a empresa claramente mais valiosa (receita, clientes, produto pronto) e some uma folga de uns seis meses para atrasos. Teste esse prazo no cenário pessimista; se não fechar, o caixa é curto. Se a sua conta der entre 18 e 24 meses, prefira 24: hoje a captação costuma demorar mais do que o planejado.

Mais dinheiro dá margem para atravessar um período ruim, mas uma rodada grande com condições sufocantes cria outro problema. Ao comparar propostas, seja de investidores-anjo (pessoas que investem o próprio dinheiro em empresas no começo) ou de fundos de capital de risco (gestoras que investem dinheiro de terceiros em empresas que podem crescer rápido), lembre que de onde vem o dinheiro, o que esperam dele e quanto controle você mantém pesam tanto quanto o valor anunciado.

Para guardar

• Prazo = meses até a próxima meta + folga de ~6 meses.
• Teste o prazo no cenário pessimista.
• Fôlego e condições se avaliam juntos.

Para aprofundar no INEMA

Explicando

Responda com números: quais são os custos fixos por mês? Quanto custa crescer? Se o produto ganhar mais clientes, quanto sobe a conta de infraestrutura? Quanta folga você precisa para atrasos ou para um contrato que demora mais que o previsto?

Faça a simulação otimista e a pessimista. Depois pergunte se vai precisar de outra rodada.

Cuidado com a armadilha da avaliação (quanto o investidor diz que a empresa vale): captar com avaliação alta e depois precisar de dinheiro com avaliação menor faz você entregar muito mais da empresa do que esperava. A maior rodada disponível nem sempre é a melhor.

Para guardar

• Custos fixos, custo de crescer, infraestrutura por cliente, folga.
• Sempre dois cenários: bom e ruim.
• Avaliação alta hoje pode custar caro amanhã.

Para aprofundar no INEMA

Explicando

Um ritmo prático é dividir em níveis: uma verificação rápida semanal e uma análise mais profunda mensal.

Um terceiro nível, com testes bem mais abrangentes (e mais caros), pode entrar a cada trimestre. Esse nível completo ainda exige um especialista ou uma ferramenta avançada; enquanto isso, um especialista contratado pode fazer esse papel.

Com o tempo, guarde os padrões encontrados em cada rodada: assim os testes ficam mais úteis e você não precisa explicar a mesma abordagem ao agente toda vez.

Para guardar

• Semanal: rápido.
• Mensal: profundo.
• Trimestral: completo, com especialista se preciso.

Para aprofundar no INEMA

Explicando

“Modelo sem censura” é um modelo de IA em que alguém removeu as travas que o fazem recusar pedidos arriscados. Só isso não o transforma numa ferramenta de segurança: o software em volta do modelo define quais ferramentas ele pode usar, o que ele memoriza, como dá seguimento a uma descoberta e o que tenta quando uma abordagem falha.

Um sistema feito sob medida para testes de segurança dá ao modelo um fluxo de trabalho muito mais útil que uma janela genérica de bate-papo. Palestras de conferências de segurança, como a Black Hat, são uma boa base para ver como esses agentes e suas ferramentas são montados.

Por isso vale separar sempre o modelo da estrutura que o envolve: o mesmo modelo dá resultados muito diferentes conforme o sistema é construído.

Para guardar

• Modelo ≠ sistema.
• Ferramentas, memória e estratégia fazem a diferença.
• Mesmo modelo, resultados diferentes.

Para aprofundar no INEMA

Explicando

Rodar por conta própria dá mais controle sobre a configuração. Um serviço hospedado cuida da infraestrutura e cobra por essa comodidade. O RunPod, um serviço que aluga por hora computadores com placa de vídeo (GPU) potente, é uma opção para hospedar o modelo quando sua máquina não dá conta.

Separe onde o modelo roda de onde as ferramentas rodam. Pôr o modelo na nuvem não leva automaticamente o resto do fluxo de testes junto.

E sempre: testes só com permissão do dono do sistema e com o escopo (o que pode e o que não pode ser testado) combinado por escrito antes de começar.

Para guardar

• Local = controle.
• Provedor = conveniência paga.
• Modelo e ferramentas podem morar em lugares diferentes.

Para aprofundar no INEMA

Explicando

Os modelos de ponta entendem melhor o que você quis dizer, então dá para deixar mais coisas subentendidas.

Com modelos menores, funciona dar objetivos mais claros, mais contexto e mais direção quando eles empacam.

Num trabalho de segurança, tudo começa pela pergunta específica do cliente: os dados dos clientes estão expostos? Uma trava de pagamento pode ser burlada? Ou é uma análise geral? São trabalhos diferentes, e o pedido e o escopo precisam refletir isso.

Para guardar

• Modelo de ponta: pode subentender.
• Modelo menor: objetivo, contexto e direção.
• O escopo nasce da pergunta do cliente.

Para aprofundar no INEMA

Explicando

Pense num teste autorizado numa loja virtual pequena: o agente tenta comprar um produto mudando o preço no meio do caminho.

Há uma diferença grande entre o agente tentar algo e provar que funcionou. Ver uma tentativa de alterar um preço não prova que o servidor (o computador da loja que registra o pedido de verdade) aceitou a alteração.

Durante os testes o sistema junta informação: uma abordagem que falhou pode revelar um endereço ou detalhe que vale investigar na próxima tentativa. Na prática, ainda vale ter uma pessoa orientando o agente; anote o que funcionou para repetir o teste sem explicar tudo de novo.

Para guardar

• Tentativa ≠ prova.
• Cada falha pode ensinar algo para a próxima.
• Ainda precisa de uma pessoa orientando.

Para aprofundar no INEMA

Explicando

Construir algo sem olhar os detalhes de engenharia e inspecionar um sistema atrás de falhas são atividades muito diferentes. Segurança exige atenção aos detalhes.

Virar desenvolvedor e depois se requalificar em segurança dá muito trabalho — e pode nem ser do seu interesse.

Algumas pessoas se dão melhor ensinando, prestando consultoria ou ajudando empresas a perceber quando precisam de um especialista. Escolha a função antes de encarar mais um currículo longo.

Para guardar

• Construir e inspecionar são trabalhos diferentes.
• Escolha a função antes do curso.
• Ensinar e orientar também são caminhos.

Para aprofundar no INEMA

Explicando

Boa parte do aprendizado vem de testar os próprios aplicativos e ler, passo a passo, o que o agente tentou.

Quando aparecer algo que você não entende, pare e investigue: o que significa esse termo? Por que ele tentou esse caminho? O que impediria esse problema?

Decida também se o interesse é segurança ofensiva (atacar para achar falhas, com autorização) ou defensiva (proteger) — os cursos são diferentes. E seja transparente com clientes sobre a sua experiência: não ter certificação não é problema, fingir ser especialista em tudo é.

Para guardar

• Teste o que é seu e leia os passos do agente.
• Parou de entender? Investigue na hora.
• Ofensivo ou defensivo: escolha antes do curso.

Para aprofundar no INEMA

Explicando

Uma abordagem melhor: empresas do setor deles estão enfrentando certos problemas — eles gostariam de ajuda para verificar se isso os afeta também?

Dê um motivo para a conversa. Peça permissão. Explique o que você pode examinar e para o que está qualificado.

Chegar dizendo “encontrei todos os seus defeitos” é um péssimo começo de relacionamento.

Para guardar

• Fale do setor, não dos defeitos deles.
• Peça permissão antes de olhar.
• Diga com clareza o que você sabe fazer.

Para aprofundar no INEMA

Explicando

A empresa pode já ter uma ferramenta que atende tudo o que ela precisa. Dizer que a sua versão personaliza mais pode não fazer diferença para ela.

Um sistema empresarial de base serve para as pessoas construírem em cima — não é promessa de que toda empresa precisa de alguém para instalar exatamente aquilo.

A oferta fica mais forte dentro de um serviço maior: entender o negócio, descobrir o que está faltando e entregar o sistema se ele resolver esse problema. Mais um recurso, por si só, não cria demanda.

Para guardar

• Recurso novo não cria demanda.
• Comece pelo problema do negócio.
• O sistema entra se resolver o problema.

Para aprofundar no INEMA

Explicando

Primeiro, os nomes: a API é a porta que o seu sistema oferece para outros programas conversarem com ele. O servidor MCP (o conector usado pelos assistentes de IA) e a CLI (a versão de linha de comando, usada no terminal) são dois jeitos de usar essa mesma porta.

Escreva no AGENTS.md (o arquivo de instruções que os agentes de programação leem ao abrir o projeto) uma regra simples: quando a API mudar, confira o servidor MCP e a CLI e aplique as mudanças necessárias.

A API é a base de que essas interfaces dependem. Mudar a base e esquecer o que foi construído em cima vira problema de organização e manutenção.

Cada lançamento só termina quando as interfaces ligadas a ele também receberam a mudança.

Para guardar

• Regra no AGENTS.md.
• API é a base; MCP e CLI ficam em cima.
• Lançamento só fecha com tudo atualizado.

Para aprofundar no INEMA

Explicando

Alguns provedores de IA têm programas para profissionais de segurança: você se identifica, explica o trabalho e o provedor libera um uso mais amplo, com regras e acompanhamento. Um modelo com as travas removidas não tem nada disso.

No trabalho defensivo, deixe claro o que é seu, o que o cliente autorizou e o que você está testando. Não espere que o provedor adivinhe o contexto de um pedido ambíguo.

Uma diferença prática: no programa do provedor, você paga pelo uso e ele cuida da hospedagem; o modelo próprio você mesmo hospeda e mantém.

Para guardar

• Programa aprovado ≠ modelo sem travas.
• Contexto e autorização sempre explícitos.
• No programa, a operação fica com o provedor.

Para aprofundar no INEMA

Explicando

Tenha um motivo para o projeto de treino. Um modelo pequeno para uma tarefa específica é uma proposta bem diferente de tentar criar mais um modelo de uso geral.

Para a maioria, o caminho mais útil é aprender a adaptar modelos que já existem e tirar deles o comportamento que você precisa.

E desconfie das afirmações sobre modelos que “melhoram sozinhos”: nem toda promessa desse tipo prova que isso já acontece do jeito que as pessoas imaginam.

Para guardar

• Treinar do zero só com motivo.
• Adaptar modelo pronto resolve mais.
• “Melhora sozinho” exige prova.

Para aprofundar no INEMA

Explicando

Parâmetros são os “números aprendidos” do modelo; quanto mais parâmetros, mais memória ele ocupa. Uma regra prática aproximada é reservar para o modelo cerca de metade da RAM — aqui, uns 24 GB. É uma regra conservadora para começar (o Mac até permite usar mais), não um limite técnico.

A conta: na versão comprimida mais comum (quantizada em 4 bits), cada bilhão de parâmetros ocupa por volta de 0,6 GB. Um modelo de 20 bilhões fica perto de 12 GB, e o resto dos 24 GB cobre a memória da conversa. O sistema e os outros programas continuam com a outra metade.

Não escolha de cara o maior modelo que cabe na máquina: com folga, o computador continua usável enquanto o modelo roda. Em Mac, procure a versão MLX do modelo, feita para os chips da Apple.

Para guardar

• 48 GB ÷ 2 ≈ 24 GB para o modelo.
• 4 bits: ~0,6 GB por bilhão → 20 bi ≈ 12 GB.
• No Mac, versão MLX.

Para aprofundar no INEMA