noticias
Seus agentes de IA estão deixando rastros por toda parte e a groundcover quer mantê-los dentro da sua nuvem
**A startup afirma que logs, prompts, traces e resultados de investigações não precisam atravessar a infraestrutura de um fornecedor de observabilidade. Sua proposta combina eBPF, OpenTelemetry e um agente capaz de analisar incidentes dentro da conta do próprio cliente. A arquitetura enfrenta um problema real: agentes de IA já produzem mais telemetria do que muitas equipes conseguem compreender. Mas manter os dados “em casa” não resolve sozinho permissões excessivas, erros semânticos nem a concentração de poder em outra camada do sistema.**
Durante anos, observar um sistema em produção significava acompanhar sinais relativamente familiares. Uso de processador, consumo de memória, tempo de resposta, quantidade de erros, requisições por segundo e disponibilidade permitiam que equipes reconstruíssem boa parte do que havia acontecido.
Uma aplicação recebia uma solicitação, consultava algum serviço, acessava o banco de dados e devolvia uma resposta. A sequência podia ser longa e distribuída, mas ainda possuía alguma previsibilidade. Logs, métricas e traces foram criados para acompanhar esse fluxo.
Agentes de inteligência artificial quebraram parte dessa simplicidade.
Uma única solicitação pode fazer o sistema consultar um modelo, reorganizar o plano, buscar documentos, chamar uma ferramenta, interpretar o resultado, perceber que falhou, repetir a tentativa com outros parâmetros e finalmente produzir uma resposta. Em operações mais complexas, vários agentes podem dividir a tarefa, compartilhar memória e utilizar serviços diferentes.
A aplicação não executa apenas um caminho. Ela decide qual caminho tentará executar.
Quando algo dá errado, a equipe precisa descobrir muito mais do que qual servidor ficou lento. Precisa saber qual modelo estava ativo, que versão do prompt foi utilizada, quais documentos foram recuperados, por que determinada ferramenta foi escolhida, quantas tentativas ocorreram e em que ponto o contexto começou a se desviar.
Também precisa descobrir quanto custou o erro.
É sobre essa nova confusão operacional que a groundcover está construindo sua expansão. A startup recebeu US$ 100 milhões numa rodada Série C e passou a apresentar sua plataforma não apenas como ferramenta para engenheiros, mas como infraestrutura de observabilidade para engenheiros e agentes.
Sua tese central é simples: os dados mais sensíveis de uma operação não deveriam sair da nuvem da empresa apenas para que outra inteligência artificial os analise.
A frase funciona muito bem comercialmente. Também expõe uma das maiores contradições da adoção empresarial de agentes.
Para vigiar a IA, empresas estão entregando mais dados a outra IA
A observabilidade já trabalha com informações delicadas.
Logs podem conter identificadores de usuários, trechos de requisições, mensagens de erro, nomes de tabelas, caminhos internos, tokens esquecidos por desenvolvedores e detalhes sobre a arquitetura. Traces revelam como serviços se comunicam. Métricas mostram padrões de utilização, horários de pico e mudanças de comportamento.
Quando um agente de IA entra nessa estrutura, o volume e a sensibilidade aumentam.
Prompts podem carregar contratos, códigos, conversas internas e dados de clientes. Respostas podem incluir informações recuperadas de bancos privados. Chamadas de ferramentas revelam o que o agente tentou fazer, quais permissões possuía e que resultados recebeu.
Para investigar esse sistema, várias plataformas enviam parte da telemetria a um serviço externo e depois submetem o material a um modelo de IA. Surge então uma cadeia de confiança composta pelo cliente, pela empresa de observabilidade e pelo fornecedor do modelo.
O software criado para explicar onde os dados estão circulando pode ser responsável por fazê-los circular ainda mais.
A groundcover propõe inverter essa lógica. Seu plano de dados, responsável por coletar, armazenar e consultar telemetria, roda dentro da conta de nuvem do cliente. O agente de investigação é apresentado como parte dessa arquitetura, usando serviços de modelos associados ao ambiente contratado pela própria empresa.
A organização mantém os dados perto dos sistemas que os produziram e evita copiar grandes volumes para o ambiente central do fornecedor.
É uma proposta tecnicamente coerente, especialmente para bancos, serviços de saúde, órgãos públicos e empresas submetidas a requisitos rigorosos de residência de dados.
Mas “dentro da sua nuvem” precisa deixar de ser uma expressão promocional e tornar-se uma descrição verificável.
BYOC não é uma palavra mágica
O modelo utilizado pela groundcover é conhecido como BYOC, abreviação de *bring your own cloud*. Em vez de armazenar toda a telemetria num serviço SaaS convencional, a plataforma executa sua camada de dados dentro da infraestrutura do cliente.
O conceito parece simples, mas diferentes fornecedores utilizam a mesma sigla para arquiteturas bastante diferentes.
Em algumas ofertas, o software é instalado na conta do cliente, mas continua sendo integralmente administrado pelo fornecedor, que mantém amplas permissões operacionais. Em outras, apenas uma parte dos dados permanece local, enquanto traces ou consultas atravessam serviços externos.
Há ainda sistemas em que o armazenamento fica dentro da empresa, porém a camada de inteligência artificial precisa enviar informações a uma API pública para gerar a análise.
A groundcover afirma separar o plano de controle do plano de dados. O primeiro administra configurações e atualizações; o segundo armazena e processa a telemetria dentro da nuvem do cliente. O acesso operacional do fornecedor seria limitado e auditável, sem alcançar livremente os dados de produção.
A arquitetura é mais interessante do que simplesmente instalar uma cópia do SaaS na conta de outra pessoa.
Mesmo assim, a promessa precisa ser examinada em cada implantação.
Qual provedor de modelo está sendo utilizado? A chamada ocorre por um serviço privado da própria nuvem ou por uma API externa? Quais dados entram no contexto? Existem filtros para credenciais e informações pessoais? O fornecedor consegue acessar consultas de suporte? Quais metadados ainda são enviados ao plano de controle?
A resposta pode variar conforme AWS, Azure, Google Cloud, modelo escolhido e configuração de rede.
Uma arquitetura pode permitir soberania. Não consegue obrigar o cliente a configurá-la corretamente.
O eBPF observa o que a aplicação preferia não contar
A principal base técnica da groundcover é o eBPF, tecnologia originada no kernel Linux que permite executar pequenos programas verificados em pontos estratégicos do sistema operacional.
Na observabilidade, isso possibilita acompanhar conexões, processos, chamadas e tráfego sem alterar manualmente cada aplicação. O sensor fica numa camada inferior à maioria dos serviços e observa o comportamento real da infraestrutura.
Essa posição possui uma vantagem importante na era dos agentes.
Instrumentação tradicional depende de desenvolvedores adicionarem bibliotecas, configurarem traces e decidirem quais informações serão registradas. Serviços antigos podem ter cobertura incompleta. Código gerado por IA pode chegar com padrões diferentes ou simplesmente sem qualquer instrumentação.
O eBPF consegue enxergar parte do sistema mesmo quando ninguém se lembrou de prepará-lo para ser observado.
Se um serviço começa a conversar com um banco de dados desconhecido, o tráfego existe no kernel. Se um agente cria um novo processo ou passa a chamar outro componente, há sinais dessa atividade abaixo da camada da aplicação.
A groundcover argumenta que isso oferece uma forma de verdade operacional. O sistema observa aquilo que o agente fez, não apenas aquilo que o próprio código decidiu registrar sobre o que fez.
A distinção é valiosa. Logs podem ser incompletos, manipulados ou simplesmente errados. Um agente comprometido poderia até produzir registros destinados a esconder determinada atividade.
O kernel oferece uma perspectiva mais difícil de falsificar a partir da aplicação.
Mas não oferece onisciência.
Ver o pacote não significa compreender a intenção
O eBPF é excelente para responder perguntas sobre processos, conexões, chamadas do sistema e comportamento da rede. Ele não sabe, sozinho, por que um modelo escolheu determinada ferramenta ou se uma resposta estava factualmente correta.
Pode mostrar que o agente consultou três bancos, chamou uma API quatro vezes e enviou determinada quantidade de dados. Para entender o significado da operação, ainda será necessário correlacionar esses sinais com prompts, respostas, contexto recuperado e informações fornecidas pelo aplicativo.
Tráfego criptografado também impõe limites. Dependendo da arquitetura, o sensor pode observar origem, destino, volume e duração sem conseguir interpretar todo o conteúdo sem integração adicional.
É por isso que a groundcover combina eBPF com OpenTelemetry e conectores específicos.
O eBPF fornece cobertura ampla da infraestrutura. O OpenTelemetry acrescenta semântica em pontos instrumentados: qual modelo foi chamado, quantos tokens foram utilizados, qual agente iniciou a operação e quais ferramentas participaram do fluxo.
As duas camadas são complementares.
A narrativa de “zero instrumentação” deve ser interpretada com cuidado. É possível obter visibilidade operacional valiosa sem alterar código, mas reconstruir toda a lógica de uma aplicação de IA pode exigir sinais inseridos no nível em que essa lógica existe.
O kernel consegue dizer que uma ferramenta foi chamada. A aplicação pode precisar informar qual decisão levou a essa chamada.
A telemetria dos agentes é muito mais do que latência
Monitorar um chatbot simples pode limitar-se a tempo de resposta, quantidade de erros e consumo de tokens. Um agente que executa tarefas exige um modelo muito mais completo.
A empresa precisa acompanhar a sequência de decisões, chamadas a ferramentas, tentativas, falhas, custos e efeitos produzidos fora do modelo. Também deve registrar qual versão do agente estava em execução, quais permissões possuía e quais fontes foram utilizadas.
O OpenTelemetry já trabalha em convenções semânticas para padronizar esse tipo de registro.
Uma chamada pode carregar identificadores do agente, da conversa e do fluxo. Pode registrar o provedor, o modelo, tokens de entrada e saída, documentos recuperados, argumentos enviados a ferramentas e resultados recebidos.
Isso torna possível reconstruir uma execução sem depender apenas do texto final.
Considere um agente de atendimento que concede um desconto indevido. O erro pode ter começado no documento recuperado, num prompt antigo, numa ferramenta que devolveu informação incompleta ou numa interpretação errada feita pelo modelo.
Sem traces conectados, todas essas etapas aparecem como caixas separadas.
Com telemetria adequada, a equipe consegue seguir o caminho inteiro.
Essa visibilidade, entretanto, cria outro problema: o registro pode conter praticamente tudo aquilo que a empresa desejava proteger.
O sistema que melhora a auditoria também cria um arquivo perfeito para o atacante
Uma plataforma de observabilidade de agentes pode concentrar prompts, respostas, chamadas, documentos, topologia, credenciais acidentalmente expostas e detalhes sobre falhas.
É um mapa operacional quase ideal.
Caso essa base seja comprometida, o invasor não encontrará apenas dados históricos. Poderá aprender como os agentes funcionam, quais ferramentas conseguem utilizar, quais mecanismos de segurança falharam e onde estão os componentes mais sensíveis.
Manter a telemetria na nuvem do cliente reduz o número de cópias externas e pode diminuir o raio de exposição. Não elimina a necessidade de proteger o próprio ambiente.
A plataforma deverá possuir controles de acesso rigorosos, criptografia, registros de auditoria, separação entre equipes e políticas de retenção. Nem todo desenvolvedor precisa visualizar prompts que contêm dados pessoais. Nem todo analista precisa acessar os resultados de ferramentas financeiras.
Também será necessário limitar o agente de observabilidade.
Para investigar incidentes, ele receberá acesso amplo a logs, métricas e traces. Se também puder criar monitores, abrir chamados, alterar configurações ou sugerir correções diretamente em ferramentas de desenvolvimento, sua conta torna-se extremamente privilegiada.
Uma injeção de prompt escondida num log ou num documento pode tentar influenciar a investigação.
O agente responsável por observar outros agentes não está automaticamente imune aos mesmos ataques.
Logs também podem conter comandos hostis
Modelos não distinguem naturalmente entre dado e instrução. Essa confusão está no centro dos ataques de *prompt injection*.
Imagine que uma aplicação processe conteúdo enviado por usuários. Um atacante insere uma frase maliciosa. O texto aparece num log. Mais tarde, o agente de observabilidade lê esse registro durante uma investigação.
Caso o sistema não trate o conteúdo como informação não confiável, poderá interpretar o texto como ordem.
O risco aumenta quando o agente possui conectores com Slack, Linear, Jira, Cursor, Codex ou ferramentas de operação. Uma mensagem escondida no material analisado poderia tentar induzi-lo a criar um chamado enganoso, revelar dados ou iniciar uma ação inadequada.
A groundcover afirma manter as sugestões sob revisão humana antes da aplicação. Essa barreira é importante, mas não deve ser confundida com solução definitiva.
Pessoas aprovam recomendações rapidamente, especialmente durante incidentes.
A arquitetura precisa aplicar separação clara entre conteúdo observado e comandos autorizados, limitar ferramentas, validar argumentos e registrar cada decisão. Também deve impedir que um agente utilize a telemetria como canal para escapar de suas permissões originais.
Observabilidade com IA amplia capacidade investigativa. Também transforma logs em parte da superfície de ataque.
Agentes geram uma explosão de dados porque erram em silêncio e tentam novamente
A groundcover descreve uma explosão na quantidade de telemetria. A tendência faz sentido.
Aplicações tradicionais costumam registrar uma sequência relativamente curta por solicitação. Agentes podem entrar em loops, repetir consultas, alternar modelos, chamar ferramentas e manter sessões durante minutos ou horas.
Cada tentativa produz tokens, traces, logs e eventos.
Um agente pode alcançar o resultado final depois de dez caminhos fracassados. Para o usuário, houve apenas uma resposta. Para a infraestrutura, ocorreram dezenas de operações.
Esse comportamento dificulta previsão de custos.
Um modelo mais barato pode gerar uma conta maior caso o agente repita chamadas sem controle. Uma ferramenta lenta pode aumentar o tempo total e estimular novas tentativas. Um contexto mal organizado pode fazer o sistema recuperar documentos em excesso.
A observabilidade precisa revelar esses padrões antes que apareçam apenas na fatura.
Também precisa evitar registrar tudo indefinidamente.
Guardar cada prompt, resposta e chamada em alta resolução pode criar uma conta de armazenamento comparável ou superior ao custo do próprio modelo. A plataforma precisará aplicar retenção diferenciada, amostragem e redução de dados sem destruir justamente as evidências necessárias durante um incidente.
A inteligência artificial tornou a telemetria mais importante e mais cara no mesmo movimento.
O modelo por nó tenta escapar do imposto sobre o volume
Plataformas tradicionais de observabilidade frequentemente cobram pela quantidade de dados ingeridos ou armazenados. Esse modelo cria um incentivo problemático: quando o sistema gera mais informação, a empresa paga mais justamente no momento em que precisa investigar.
Equipes começam então a descartar logs, reduzir traces e diminuir períodos de retenção.
Economizam durante o funcionamento normal e descobrem, no incidente, que eliminaram a única evidência útil.
A groundcover cobra principalmente com base na infraestrutura observada, e afirma não adicionar margem sobre tokens utilizados pelo Agent Mode. O cliente paga diretamente ao provedor do modelo e pode definir limites por usuário ou equipe.
A abordagem torna o custo mais previsível, mas transfere despesas para outras linhas.
Armazenamento, processamento, rede e inferência continuam existindo dentro da conta de nuvem do cliente. O fornecedor deixa de cobrar por certos dados, mas a nuvem não deixa de enviar a fatura.
BYOC muda quem apresenta a conta. Não elimina a conta.
Para empresas grandes, essa troca pode ser vantajosa porque permite negociar diretamente com o provedor e controlar retenção. Para operações menores, administrar a infraestrutura poderá custar mais tempo e conhecimento do que uma solução SaaS convencional.
Soberania possui preço operacional.
O agente de observabilidade quer transformar conhecimento informal em produto
A proposta do Agent Mode não se limita a responder perguntas sobre gráficos.
A groundcover quer que o sistema aprenda como as equipes investigam incidentes e transforme esse conhecimento em capacidade disponível para toda a organização.
Hoje, boa parte do funcionamento de sistemas complexos vive na memória de poucas pessoas. Um engenheiro sabe que determinada latência costuma aparecer depois de uma implantação específica. Outro conhece uma dependência não documentada. Durante um incidente, alguém precisa acordar o profissional certo.
Um agente com acesso à telemetria, aos históricos e aos procedimentos poderia reduzir essa dependência.
Ele poderia preparar mapas de topologia, resumir incidentes, criar consultas e sugerir monitores. Ao entrar numa investigação, recuperaria o contexto acumulado e tentaria reproduzir parte do julgamento dos especialistas.
A promessa é atraente porque empresas possuem dificuldade para transferir conhecimento.
Também existe o risco de transformar conclusões provisórias em memória institucional.
Um diagnóstico incorreto pode ser repetido em incidentes futuros. Uma correlação circunstancial pode virar regra. Procedimentos antigos permanecem disponíveis mesmo depois de mudanças na arquitetura.
O agente precisa distinguir aquilo que foi observado, aquilo que alguém inferiu e aquilo que foi confirmado.
Sem essa separação, a empresa não estará preservando conhecimento. Estará automatizando folclore operacional.
Telemetria não é verdade absoluta
Logs, traces e métricas são evidências produzidas por sistemas. Não representam necessariamente a realidade completa.
Um contador pode estar errado. Um relógio pode estar dessincronizado. Um serviço pode deixar de registrar eventos. Uma falha pode ocorrer fora da região observada.
Mesmo dados capturados pelo kernel exigem interpretação.
Uma conexão mostra que dois componentes conversaram. Não prova que a informação enviada era correta ou autorizada. Um processo consumindo memória pode ser causa, consequência ou comportamento esperado.
O agente de observabilidade adiciona outra camada de inferência.
Ele conecta sinais e produz uma narrativa: o serviço ficou lento porque a memória acabou, o que aumentou repetições e elevou o consumo de tokens. Essa explicação pode ser extremamente útil. Ainda precisa ser testada.
A interface em linguagem natural aumenta o risco de confiança excessiva. Uma conclusão apresentada num parágrafo fluido parece mais definitiva do que um conjunto de gráficos contraditórios.
O bom sistema deverá mostrar as consultas, dados e hipóteses usados em cada resposta.
A groundcover afirma que as consultas geradas pelo Agent Mode ficam visíveis e podem ser reutilizadas. Esse desenho é melhor que um agente completamente opaco.
Mesmo assim, visibilidade da consulta não garante correção da interpretação.
A padronização será mais importante que qualquer fornecedor
O mercado de observabilidade de IA está se formando rapidamente. Groundcover, Datadog, Grafana, Arize, LangSmith, Microsoft e vários outros participantes oferecem partes da solução.
Empresas não deveriam depender de um formato proprietário para registrar a atividade de seus agentes.
Sem padrões comuns, migrar de plataforma exigirá reescrever instrumentação, perder históricos e adaptar dashboards. O fornecedor que armazenar a telemetria controlará também o custo de saída.
As convenções de IA do OpenTelemetry tentam criar uma linguagem comum.
Modelos, agentes, ferramentas e sistemas de recuperação podem registrar operações usando atributos reconhecíveis por diferentes plataformas. Isso não elimina extensões específicas, mas reduz a dependência de um produto.
A groundcover apoia OpenTelemetry, embora destaque que sua coleta por eBPF consegue enxergar serviços que não foram instrumentados manualmente.
A combinação parece sensata: padrão onde existe semântica explícita; captura automática onde a equipe esqueceu ou não conseguiu instrumentar.
O risco aparece quando o fornecedor apresenta a cobertura automática como substituta do padrão. O dado observado precisa continuar exportável, compreensível e utilizável fora da plataforma.
A melhor observabilidade não é apenas aquela que vê tudo. É aquela que não torna o cliente cego caso decida sair.
“Nunca sair da nuvem” pode tornar-se a próxima exigência empresarial
Durante a primeira onda da IA generativa, empresas enviaram informações a APIs externas porque precisavam experimentar rapidamente. A prioridade era descobrir casos de uso.
A fase seguinte será menos tolerante.
À medida que agentes passam a acessar produção, sistemas financeiros, documentos e ferramentas internas, arquitetura e residência dos dados tornam-se centrais. Uma demonstração pode utilizar informações fictícias. Um agente operacional precisa trabalhar com a realidade da empresa.
Organizações reguladas exigirão controle sobre onde prompts, respostas e traces são armazenados. Equipes de segurança perguntarão quais fornecedores participam de cada chamada e quanto tempo os dados permanecem disponíveis.
A observabilidade não escapará dessa cobrança.
Na verdade, poderá enfrentá-la primeiro, porque seu trabalho consiste em reunir dados provenientes de toda a infraestrutura.
A groundcover está apostando que BYOC deixará de ser diferencial e se tornará requisito.
Essa previsão parece plausível. A questão é se a empresa conseguirá manter simplicidade operacional enquanto preserva separação real entre planos, fornecedores e modelos.
Segurança por arquitetura costuma ser mais forte que segurança por contrato. Também é muito mais difícil de construir e provar.
O que muda para as empresas agora
Organizações que já possuem agentes em produção deveriam começar pelo inventário.
Quais agentes existem? Que modelos utilizam? Quais ferramentas conseguem acionar? Que dados entram no contexto? Onde prompts e respostas são armazenados? Quem consegue consultar esses registros?
Sem essa base, comprar uma nova plataforma de observabilidade apenas centraliza a confusão.
Também é necessário definir quais sinais importam. Nem todo prompt precisa ser armazenado integralmente. Em alguns casos, registrar metadados, identificadores e avaliações será suficiente. Conteúdos sensíveis podem exigir mascaramento ou retenção curta.
Permissões devem seguir o princípio do menor privilégio. Um agente que investiga latência não precisa necessariamente acessar o conteúdo completo de transações. Um agente que cria dashboards não deveria aplicar mudanças diretamente em produção.
As empresas precisam ainda testar a própria arquitetura de BYOC.
Não basta confiar na apresentação. É preciso verificar rotas de rede, chaves, logs de acesso, integrações com modelos e comportamento durante suporte. Uma consulta aparentemente interna pode acionar serviços externos.
Por fim, conclusões da IA devem permanecer vinculadas às evidências. O agente pode acelerar a investigação, mas não pode tornar-se autoridade invisível sobre a causa de cada incidente.
A groundcover acertou o problema — ainda precisa provar toda a solução
A tese de que telemetria sensível deve permanecer sob controle do cliente é sólida.
Também faz sentido utilizar eBPF para capturar comportamento real da infraestrutura, complementar essa visão com OpenTelemetry e permitir que um agente consulte os dados em linguagem natural.
A proposta ataca três dificuldades concretas: cobertura incompleta, fragmentação entre sinais e exposição causada pelo envio de produção para serviços externos.
Mas o mercado não deve confundir uma arquitetura promissora com uma solução automática.
eBPF não compreende sozinho a lógica de um agente. BYOC não elimina configurações erradas. Um modelo dentro da conta do cliente continua vulnerável a instruções maliciosas, permissões excessivas e interpretações incorretas.
A telemetria pode permanecer na nuvem e ainda ser acessada pela pessoa errada. O agente pode mostrar todas as consultas e ainda chegar à conclusão errada. O sistema pode reduzir dependência do SaaS e aumentar dependência de determinado provedor de nuvem.
Toda escolha desloca o ponto de confiança.
A groundcover recebeu US$ 100 milhões porque investidores acreditam que observar agentes será uma categoria central da infraestrutura. É uma aposta razoável. Empresas estão distribuindo autonomia antes de construir mecanismos suficientes para reconstruir o que essa autonomia fez.
O mercado começou criando agentes capazes de agir.
Agora descobre que precisa de outro agente para explicar as ações do primeiro.
A nova caixa-preta precisa de janelas — não de outra caixa-preta
Agentes de IA não fracassam apenas quando retornam erro. Podem concluir uma tarefa pelo caminho errado, utilizar informações inadequadas, gastar recursos excessivos e produzir efeitos que parecem corretos até alguém examinar as etapas.
A observabilidade é o mecanismo que transforma essas etapas em evidência.
Manter a evidência dentro da infraestrutura do cliente reduz exposição e amplia controle. É uma escolha especialmente importante quando prompts e traces contêm o próprio mapa da empresa.
Mas a soberania verdadeira exige mais que localização.
Exige formatos abertos, permissões restritas, acesso auditável, retenção consciente e capacidade de trocar tanto a ferramenta de observabilidade quanto o modelo que realiza as análises.
A groundcover está certa ao dizer que os dados não deveriam sair apenas porque alguém deseja fazer uma pergunta sobre eles.
A parte mais difícil vem depois: garantir que o agente autorizado a responder essa pergunta não ganhe poder suficiente para transformar observabilidade em outra fonte de risco.
A era dos agentes está criando uma nova disciplina operacional. Não basta saber se o sistema está online. Será necessário saber o que decidiu, por que decidiu, quanto gastou, quais ferramentas utilizou e quem permitiu cada ação.
Empresas que não conseguirem responder a essas perguntas estarão apenas automatizando aquilo que ainda não sabem controlar.
A telemetria pode permanecer na nuvem.
A responsabilidade, infelizmente para quem procura outro atalho tecnológico, continuará pertencendo às pessoas.
👉 Dúvida? Então veja mais em: https://pixbugtech.com/linksuteis