Uma empresa identifica a necessidade de reduzir perdas em seu processo produtivo. Em seguida, recebe uma lista de fornecedores. Para que essa aproximação seja útil, será necessário compreender por que aqueles parceiros foram indicados, quais requisitos conseguem atender e o que ainda precisa ser verificado. Esse exemplo evidencia uma questão de projeto: como transformar informações e recomendações em um processo que ajude as pessoas a tomar decisões?
Nos dois primeiros artigos desta série, apresentei a organização de dados públicos e a proposta de um ambiente para aproximar desafios industriais, soluções e competências. O terceiro passo será analisar a plataforma. Precisamos definir seus usuários, os problemas que ela ajudará a enfrentar, as informações necessárias e os critérios para avaliar seu funcionamento. Essas definições formarão uma proposta inicial, a ser discutida com os futuros participantes.
A pesquisa pode orientar esse trabalho. A metodologia de Design Science Research, apresentada por Peffers e colaboradores, articula a identificação do problema, os objetivos da solução, o desenvolvimento, a demonstração, a avaliação e a comunicação. Para o nosso projeto, essa referência ajuda a relacionar cada recurso proposto a uma necessidade e a uma forma de avaliar sua contribuição. O desenho deverá evoluir à medida que forem obtidas as evidências ao longo da construção. [Journal of Management Information Systems]
A primeira definição é o objetivo do serviço: apoiar a estruturação de desafios empresariais, identificar parceiros potencialmente compatíveis e acompanhar os encaminhamentos. Uma conexão recomendada será uma oportunidade de cooperação. A decisão de compartilhar informações adicionais, iniciar uma conversa ou desenvolver um projeto ficará a cargo dos responsáveis envolvidos.
Os participantes terão necessidades diferentes. A empresa demandante precisará descrever seu problema, controlar sua divulgação e comparar as possibilidades. Startups, prestadores de serviços, laboratórios e pesquisadores precisarão apresentar suas ofertas e compreender o tipo de contribuição esperado. Entidades de apoio poderão ajudar a qualificar registros e acompanhar conexões. O responsável pela operação da plataforma terá de manter as regras de participação, tratar das ocorrências e monitorar a qualidade do serviço.
Esses papéis deverão ser validados por representantes dos grupos envolvidos. A mesma organização poderá oferecer uma solução e, em outro contexto, registrar uma necessidade. O cadastro deverá permitir essa participação sem exigir contas ou informações duplicadas. Entrevistas e análise de situações concretas ajudarão a identificar quais etapas já funcionam fora do ambiente digital e onde há dificuldades que o sistema pode reduzir.
O fluxo inicial proposto começará pelo registro de um desafio. A empresa informará o processo afetado, a dificuldade observada, o resultado desejado e as restrições conhecidas. A plataforma poderá pedir esclarecimentos e organizar um rascunho. Antes de disponibilizá-lo, o responsável revisará a descrição e escolherá quem poderá acessá-la. Depois, receberá possíveis conexões, examinará as justificativas e decidirá se deseja avançar.
A análise desse fluxo permite estabelecer requisitos funcionais: cadastrar organizações e ofertas, registrar e revisar desafios, localizar competências, apresentar recomendações, controlar acesso e acompanhar interações. Também surgem requisitos de qualidade, como facilidade de uso, tempo de resposta aceitável, disponibilidade e rastreabilidade. A compreensão da recomendação e a possibilidade de corrigir informações deverão fazer parte da experiência desde a primeira versão.
O modelo de informações deverá distinguir organização, competência, oferta, desafio, recomendação e interação. Uma organização pode possuir várias ofertas, cada uma com aplicações, requisitos e estágios de desenvolvimento próprios. Um desafio pode receber diferentes recomendações.
Cada aproximação poderá gerar uma conversa, um piloto ou um encerramento com motivo registrado. Essas relações permitirão acompanhar o percurso de uma necessidade sem confundir um cadastro com um resultado alcançado.
Os dados públicos continuarão contribuindo para contextualizar setores e territórios. Já os cadastros dos participantes descreverão capacidades e demandas específicas. Uma tendência setorial poderá orientar uma investigação, mas precisaremos confirmar sua pertinência junto à empresa antes de utilizá-la para caracterizar um problema individual. Pesquisas privadas também deverão manter identificação de origem, cobertura e condições de utilização.
A IA terá funções delimitadas. Durante o cadastro, poderá ajudar a transformar uma descrição livre em campos organizados, sugerir categorias e identificar lacunas. Na busca, poderá aproximar expressões diferentes que tratem de uma mesma aplicação. Na apresentação dos resultados, poderá produzir uma síntese das informações encontradas. Cada uso precisará definir suas entradas, a saída esperada, as verificações necessárias e a ação possível diante de informações insuficientes.
O matching exigirá combinar interpretação com critérios explícitos. Considere, como exemplo hipotético, uma empresa que procura uma alternativa de inspeção para um ambiente sem conexão contínua. Duas ofertas podem ter descrições semelhantes, mas uma delas exige acesso permanente à internet. Se essa restrição for obrigatória e estiver documentada, a recomendação deverá considerá-la. Quando a informação não existir no cadastro, o sistema deverá apontar a necessidade de confirmação.
Por isso, proponho uma combinação de busca textual e semântica com regras de compatibilidade. A busca localizará candidatos; os critérios ajudarão a verificar requisitos e organizar as sugestões. A descrição fornecida pelo próprio ofertante deverá aparecer identificada como tal, distinguindo-se de evidências verificadas. A ausência de candidatos adequados também deverá ser um resultado possível, acompanhado de caminhos para revisar a busca ou solicitar apoio humano.
A explicação precisará corresponder ao processo utilizado para a recomendação. O sistema deverá apresentar os atributos, registros e critérios que fundamentaram a indicação, bem como os pontos de dúvida. Um texto convincente produzido por IA, isoladamente, não demonstra por que uma oferta foi selecionada. Também evitaremos apresentar pontuações de compatibilidade como probabilidades de sucesso sem validação que autorize essa interpretação.
As diretrizes de interação humano–IA de Amershi e colaboradores oferecem referências para esse desenho. Elas recomendam tornar compreensíveis as capacidades e limitações do sistema, permitir correções, apoiar o descarte de sugestões e disponibilizar explicações sobre seu comportamento.
Aplicadas ao projeto, essas orientações se traduzem na possibilidade de editar um desafio, revisar uma classificação e discordar de uma recomendação sem perder o controle do processo. [microsoft.com]
A arquitetura conceitual deverá sustentar essas funções. Uma base operacional organizará os cadastros e os estados das interações. O repositório de dados e documentos preservará os materiais de origem e suas respectivas versões. Um serviço de busca e recomendação trabalhará com informações autorizadas. A interface permitirá revisar os registros, comparar sugestões e acompanhar os encaminhamentos. A divisão de responsabilidades facilitará a modificação de componentes e a verificação de seus efeitos.
Essa arquitetura deverá conectar-se à organização dos dados discutida no primeiro artigo. Os arquivos públicos preservados poderão alimentar conjuntos preparados para consulta, enquanto os registros operacionais terão sua própria estrutura. Os índices utilizados nas buscas serão derivados dessas fontes e precisarão acompanhar correções e alterações de acesso. A escolha das ferramentas virá depois da definição dos requisitos de escala, de manutenção e de custo.
O compartilhamento de informações também deverá ser planejado. Um desafio poderá ter uma descrição acessível à comunidade e anexos restritos a determinados interlocutores. As permissões deverão ser aplicadas antes de disponibilizar conteúdos para a busca e para os componentes de IA. A autorização para consultar um material deve ser distinguida da permissão para utilizá-lo no treinamento de modelos.
Essa preocupação se relaciona ao horizonte dos data spaces. A International Data Spaces Association descreve ambientes de compartilhamento confiáveis, apoiados em governança, políticas, modelos semânticos e protocolos acordados entre os participantes. Esses fundamentos orientarão as futuras integrações entre organizações. Nesta etapa, precisaremos definir os papéis, as condições de acesso e os procedimentos que a primeira versão conseguirá cumprir. [IDSA Knowledge Base]
A governança da IA deverá acompanhar o projeto. O AI Risk Management Framework do NIST organiza seu núcleo em quatro funções — Govern, Map, Measure e Manage —, articulando responsabilidades, compreensão do contexto, avaliação e tratamento de riscos ao longo do ciclo de vida. Usaremos essa referência para examinar situações como recomendações inadequadas, dados desatualizados e acesso indevido, vinculando cada situação a verificações e responsáveis definidos. [nvlpubs.nist.gov]
Também precisaremos planejar como avaliar a contribuição da IA. Uma primeira comparação poderá utilizar os mesmos desafios e o mesmo conjunto de ofertas em uma busca por palavras-chave e na abordagem proposta. Especialistas e usuários avaliarão a pertinência dos resultados. O piloto poderá observar o tempo necessário para encontrar interlocutores, o esforço para concluir os cadastros, a compreensão das justificativas e a progresso das conexões.
Essa avaliação deverá incluir situações difíceis: descrições incompletas, ofertas desatualizadas, requisitos incompatíveis e ausência de candidatos. O sistema precisará permitir esclarecimentos e correções. Resultados de busca, aceitação de uma sugestão e sucesso de uma implementação serão observados como eventos distintos, pois cada um permite responder a perguntas distintas sobre a utilidade da plataforma.
O histórico das interações ajudará a revisar o serviço. Uma recomendação recusada poderá decorrer de inadequação técnica, de prazo, de orçamento ou de mudança de prioridade. O registro desses motivos contribuirá para a compreensão do processo. Alterações nos critérios e nos modelos serão avaliadas antes de sua adoção, preservando-se as informações sobre quais versões produziram as recomendações examinadas.
Ao final deste terceiro passo, esperamos obter uma análise inicial que inclua objetivos, papéis, registros, fluxo de uso, requisitos e critérios de avaliação. A próxima etapa poderá transformar essas definições em um protótipo para discussão com representantes das empresas e dos provedores de soluções. A série semanal acompanhará essa evolução, registrando as decisões e as evidências que ajudarão a construir uma plataforma útil para a cooperação industrial.
Leia mais da série especial do colunista:
- Inteligência industrial começa pela organização dos dados
- Inteligência industrial para conectar problemas e soluções
Referências
- PEFFERS, Ken; TUUNANEN, Tuure; ROTHENBERGER, Marcus A.; CHATTERJEE, Samir. A Design Science Research Methodology for Information Systems Research. Journal of Management Information Systems, v. 24, n. 3, p. 45–77, 2007. DOI: 10.2753/MIS0742-1222240302.
- AMERSHI, Saleema et al. Guidelines for Human-AI Interaction. In: Proceedings of the 2019 CHI Conference on Human Factors in Computing Systems. New York: ACM, 2019. Artigo 3, p. 1–13. DOI: 10.1145/3290605.3300233.
- INTERNATIONAL DATA SPACES ASSOCIATION. What is a Data Space? IDSA Rulebook. Disponível em: Definição e fundamentos dos data spaces. Acesso em: 9 nov. 2026.
- TABASSI, Elham. Artificial Intelligence Risk Management Framework AI RMF 1.0. Gaithersburg: National Institute of Standards and Technology, 2023. NIST AI 100-1. DOI: 10.6028/NIST.AI.100-1.
Gostou? Então compartilhe:
