Perguntas sobre superinteligência para o CTO: como responder

As perguntas sobre superinteligência que um CTO enfrenta raramente tratam de quando ela chega. Tratam de prontidão (conseguimos usar modelos muito mais fortes com segurança), dependência (o que acontece se um fornecedor mudar), controle (quem pode ver, limitar e parar um agente) e responsabilidade (quem é dono da memória, das ferramentas e das decisões). O CTO que responde a essas quatro com evidências, e não com previsões, está preparado qualquer que seja o calendário.

Principais pontos

• Conselho e equipes perguntam sobre superinteligência para medir a exposição da empresa, não para colher uma previsão. Responda com estrutura, não com palpite.
• Prontidão significa papéis definidos, conhecimento da empresa acessível, limites de aprovação por escrito e uma forma de medir se o agente cumpre a função.
• A dependência é administrável quando memória, ferramentas, permissões e avaliações pertencem à empresa e o modelo é uma peça substituível.
• Controle significa que alguém consegue ver o que o agente fez, limitar o que ele alcança e pará-lo em um dia comum de trabalho.
• Responsabilidade exige uma pessoa nomeada para cada agente, registrada por escrito e revisada com regularidade.

O que o conselho realmente quer saber quando pergunta sobre superinteligência?

A maior parte das conversas de conselho sobre o tema não gira em torno de uma data. Os conselheiros querem saber se a empresa fica exposta caso os sistemas de IA se tornem muito mais capazes, e se a gestão perceberia a tempo. A equipe faz outra versão da pergunta: meu trabalho vai mudar, e quem decide? As duas são perguntas sobre estrutura.

Antes da reunião, vale alinhar definições. Termos como AGI, ASI e alinhamento são usados de forma frouxa, e o CTO que os usa com precisão dá o tom da conversa. Circule um glossário curto com antecedência para que a discussão comece com as mesmas palavras.

A posição honesta é que ninguém consegue prometer quando, ou se, existirão sistemas muito além da capacidade humana. O que o CTO pode mostrar é que a configuração da empresa não depende dessa resposta. Se os modelos ficarem mais ou menos onde estão, a configuração continua valendo a pena. Se melhorarem muito, ela absorve a melhora sem reconstrução e sem perda de controle. Estruture cada resposta assim: o que se sustenta nos dois cenários.

Uma pergunta que vale ensaiar em voz alta:

Se um modelo muito mais forte estivesse disponível no próximo trimestre, o que na nossa empresa melhoraria e o que quebraria?

Se você não consegue responder em dois minutos, as seções abaixo são a sua preparação.

Prontidão: estamos preparados para usar modelos muito mais fortes com segurança?

Prontidão não é uma sensação sobre a tecnologia. É uma lista de coisas que existem ou não existem. Um modelo mais forte colocado numa empresa com papéis indefinidos, conhecimento espalhado e sem limites de aprovação produz confusão mais rápida, não trabalho melhor.

Estas são as perguntas de prontidão para ensaiar, com uma resposta pronta para cada uma:

• Qual função entregaríamos primeiro a um agente, e qual pessoa responde por ela?
• Onde vive o conhecimento de que o agente precisa, e ele pode ser consultado sob demanda em vez de colado em prompts?
• Qual é o limite de aprovação por escrito: o que o agente pode fazer sozinho e o que sempre exige uma pessoa?
• Como medimos que o agente faz bem o trabalho, e quem revisa essa medida?
• O que fazemos no dia em que um resultado parece errado?

Note que nenhuma delas cita o nome de um modelo. É de propósito. A empresa que responde a essas perguntas está pronta para um modelo melhor porque o trabalho ao redor já está definido. A que não responde também não está pronta para o modelo atual.

As equipes fazem a mesma pergunta em palavras mais simples: esse agente será confiável o bastante para eu confiar nele, e alguém vai ouvir se não for? A sua resposta aos dois últimos itens cobre as duas coisas.

Dependência: o que acontece se o nosso fornecedor de modelo mudar?

Essa é a primeira pergunta de um conselheiro com formação financeira. O jeito útil de responder é separar três camadas: o modelo, as ferramentas ao redor dele e o conhecimento com que ele trabalha. Trocar de modelo deve ser uma mudança contida. Perder as ferramentas ou o conhecimento é a falha cara, porque é ali que está o trabalho acumulado da empresa.

Use este guia de decisão na conversa:

• Se não é possível trocar de modelo sem reescrever as instruções, as ferramentas e a memória do agente, a dependência está no seu projeto. Corrija isso antes de ampliar o escopo.
• Se a memória do agente vive apenas dentro do produto de um fornecedor, exija uma exportação e teste se você consegue lê-la. Uma exportação que ninguém abriu não é uma exportação.
• Se uma conexão de ferramenta roda com as credenciais de um único funcionário, migre-a para uma identidade de serviço com escopo definido, que sobreviva à saída dessa pessoa.
• Se depender de um único fornecedor é aceitável hoje, escreva as condições que mudariam essa decisão, como uma mudança de política, um padrão de instabilidade ou um problema de localização dos dados.
• Se as avaliações existem apenas no painel do fornecedor, refaça-as para que rodem contra qualquer modelo que você escolher.

Um segundo modelo nem sempre é a resposta, e os argumentos a favor e contra aparecem em como escolher modelo de IA para empresa. O ponto central é a portabilidade do que você construiu. Para um passo a passo mais completo sobre a troca em si, veja como migrar agentes de IA para outro fornecedor.

Controle: quem pode ver, limitar e parar o que um agente faz?

É no controle que as questões técnicas e as de governança se encontram. O conselho quer ouvir que uma pessoa pode intervir. A equipe de segurança quer ouvir como. Algumas propriedades concretas atendem às duas.

Primeiro, privilégio mínimo. Um agente deve ter apenas o acesso que a sua função exige, e cada permissão deve ser justificada por escrito. As orientações de autorização da OWASP são uma boa referência para o princípio, e ele vale para agentes exatamente como vale para pessoas e serviços.

Segundo, resistência a manipulação. Agentes leem e-mails, documentos e páginas da web, e qualquer um deles pode trazer instruções feitas para desviá-los. O OWASP Top 10 para aplicações com LLMs aponta a injeção de prompt e a autonomia excessiva como riscos permanentes. Sua resposta deve explicar quais ações o agente não pode executar sem uma pessoa, independentemente do que ele leia.

Terceiro, visibilidade. Se você não consegue reconstruir o que um agente fez, você não o controla. Rastros, logs e registros de chamadas de ferramentas, de preferência seguindo convenções comuns como o trabalho do OpenTelemetry para IA generativa, permitem responder o que aconteceu e por quê, sem adivinhação.

Quarto, um procedimento de parada. Saiba quem pode pausar um agente, com que rapidez e o que acontece com o trabalho em andamento. Depois teste uma vez, fora de um incidente.

As permissões se desviam conforme funções e ferramentas mudam, então controle é uma atividade recorrente. Uma revisão periódica de permissões, como a descrita em reestruturação da empresa e agentes de IA: donos, permissões e rotas, dá a você a evidência para mostrar ao conselho que os limites continuam sendo o que você disse.

Responsabilidade: quem é dono da memória, das ferramentas e das decisões?

As perguntas sobre responsabilidade vêm em duas formas. O conselho pergunta quem responde quando um agente erra. A equipe pergunta de quem é o conhecimento que colocou nele. Ambas pedem uma resposta escrita, não um entendimento informal.

Um registro de responsabilidade funcional nomeia, para cada agente: um dono de negócio responsável pelos resultados, um dono técnico responsável pela configuração, o local e o custodiante da memória, a lista de ferramentas conectadas e os limites de aprovação. Ele também diz o que acontece com tudo isso se o dono sair ou se a relação com o fornecedor terminar.

Um cenário ilustrativo: um diretor pergunta quem responde quando um agente de atendimento envia uma resposta errada ao cliente. O CTO abre o registro e mostra que a head de operações com clientes é a dona responsável, que o agente só podia redigir respostas para um conjunto definido de tipos de solicitação, que uma pessoa aprovava tudo o que saísse desse conjunto e que o log da interação indica exatamente qual etapa falhou. A conversa deixa de ser sobre culpa e passa a ser sobre uma correção específica. É um caso hipotético, mas mostra como é uma resposta preparada.

Responsabilidade também cobre a recuperação. Memória, configuração e instruções são ativos da empresa, então precisam de cópias que você já tenha restaurado ao menos uma vez. Salvar não basta: o teste de restauração é o que prova que a cópia funciona.

Por fim, o NIST AI Risk Management Framework oferece um vocabulário útil aqui. A ênfase em governar, mapear, medir e gerenciar o risco dá ao conselho uma estrutura reconhecível para o que você documentou.

Plano prático: prepare as respostas em poucas sessões de trabalho

Você não precisa de um programa longo para estar pronto para essas perguntas. Precisa de um inventário curto e honesto e de uma rotina para mantê-lo atualizado. Siga esta ordem:

• Liste todos os lugares em que a IA já atua na empresa, inclusive as ferramentas que pessoas adotaram por conta própria. Você não consegue responder pelo que ainda não encontrou.
• Para cada um, registre o dono, os dados que ele toca, as ferramentas que ele pode acionar e o limite de aprovação. Marque as lacunas sem rodeios.
• Escolha uma função que valha formalizar e defina o critério de sucesso em termos observáveis, como o tempo de resposta para um tipo de solicitação ou a parcela de rascunhos aceitos sem edição pelo revisor.
• Teste a portabilidade: troque o modelo por trás dessa função em um ambiente seguro e anote o que precisou ser reescrito.
• Teste uma vez o procedimento de parada e o de restauração, e registre o resultado.
• Prepare uma resposta de uma página para cada um dos quatro temas (prontidão, dependência, controle e responsabilidade) e compartilhe com a equipe antes de o conselho ver.
• Defina uma data de revisão e cumpra-a. O inventário só serve enquanto estiver atualizado.

A Be Human projeta, implanta e opera esse tipo de infraestrutura para empresas: agentes que mantêm identidade, memória, canais, ferramentas, permissões e contexto operacional sob controle humano. Um primeiro projeto define uma função útil, a memória e as ferramentas de que ela precisa, os limites de aprovação e um critério de sucesso observável. A operação gerenciada pode incluir monitoramento, avaliações recorrentes, manutenção de integrações, revisão de permissões, resposta a incidentes e melhorias controladas.

Se você quer descobrir qual é a primeira tarefa que vale entregar a um agente, faça o diagnóstico de IA gratuito da Be Human.

Perguntas frequentes

O CTO deve apresentar ao conselho um prazo para a superinteligência? Não, e dizer isso com clareza gera credibilidade. As previsões sobre o tema são incertas, e uma data confiante é fácil de contestar. Ofereça, em vez disso, uma descrição do que a sua configuração faz sob um avanço mais lento e sob um mais rápido, e de quais decisões você vai rever conforme a evidência mudar.

Empresas de médio porte precisam de uma estratégia de superinteligência? Precisam de um pequeno número de decisões duradouras, não de um grande programa. Quem é dono de cada agente, onde vive o conhecimento da empresa, como funcionam as aprovações e como trocar de fornecedor já bastam para começar. Essas decisões compensam com os modelos de hoje e seguem valendo para os melhores.

Depender de um único fornecedor de modelo é aceitável? Pode ser, se a dependência for uma escolha ponderada e não um acidente. Mantenha memória, ferramentas, permissões e avaliações sob o seu controle, de modo que a troca seja um projeto delimitado. Escreva as condições em que você trocaria e revise-as periodicamente.

Quem deve ser dono do risco de IA, o CTO ou outra pessoa? O CTO costuma ser dono da configuração técnica, mas a responsabilidade pelos resultados pertence ao dono de negócio de cada função que o agente exerce. Um patrocinador executivo e uma rotina leve de governança ligam as duas pontas. O que importa é que cada agente tenha um dono nomeado e que o conselho saiba quem é.

Orientação editorial Be Human. Exemplos são ilustrativos, salvo atribuição explícita. Fontes oferecem contexto; a implementação depende do seu processo.