Da Maturidade Tecnológica à Validação Clínica: Integrando TRL e o Modelo de Três Camadas na Inovação em Saúde


Texto em elaboração!!!

TRL não basta, validação técnica, analítica e clínica definem inovação segura em saúde

 

Aldemar Araujo Castro
Criação: 23/03/2026
Atualização: 23/03/2026
Palavras: 10611
Tempo de leitura: 30 minutos

 

Resumo

O texto propõe integrar o Technology Readiness Level (TRL) ao modelo de três camadas, validação técnica, analítica e clínica, para redefinir maturidade em saúde. Mostra que avanço tecnológico não garante segurança nem utilidade clínica, destacando o risco de falsa confiança. Introduz a matriz TRL × Camadas como estrutura para orientar desenvolvimento, evidência e responsabilidade. Demonstra aplicação prática com o FechaFeridas e traduz o modelo em ferramenta operacional com checklists e indicadores. Integra ainda ética, regulação e governança de dados. A conclusão central é que inovação em saúde exige alinhamento entre tecnologia, validação e impacto real, evitando assimetria e reduzindo risco clínico.

 

Maturidade tecnológica não é validação clínica

 

1. Introdução

Mensagem central
👉 Inovar em saúde não é apenas fazer funcionar, é justificar, com evidência, por que deve ser utilizado.

O problema invisível da inovação em saúde

A inovação em saúde vive um paradoxo silencioso. Nunca se produziu tanta tecnologia, nunca se falou tanto em inteligência artificial, e, ainda assim, grande parte das soluções desenvolvidas não consegue produzir impacto clínico real. O problema não está na falta de criatividade, tampouco na ausência de capacidade técnica. O problema está na forma como se percorre o caminho entre a ideia e a prática assistencial.

Existe uma tendência recorrente, especialmente em projetos que envolvem tecnologia digital e IA, de confundir avanço tecnológico com validação científica. Um sistema funcional, bem programado e aparentemente eficiente é rapidamente interpretado como uma solução pronta para uso clínico. Essa interpretação equivocada ignora um princípio fundamental da medicina baseada em evidências, o fato de que desempenho técnico não equivale a benefício clínico.

Na prática, isso se traduz em um erro estrutural. Projetos avançam rapidamente em termos de desenvolvimento, atingem níveis elevados de maturidade tecnológica, mas permanecem frágeis do ponto de vista da validação. O resultado é a produção de soluções que funcionam em ambiente controlado, mas falham quando inseridas na complexidade do mundo real. Em contextos assistenciais, essa falha não é apenas técnica, é potencialmente danosa.

Esse desalinhamento ocorre porque dois eixos fundamentais da inovação evoluem de forma independente. De um lado, está a maturidade tecnológica, frequentemente organizada em níveis progressivos como o Technology Readiness Level (TRL), que descreve o grau de desenvolvimento de uma tecnologia desde sua concepção até sua aplicação operacional. De outro lado, está a validação da solução, que envolve a demonstração de segurança, confiabilidade e impacto clínico.

O TRL é extremamente útil para descrever o quanto uma tecnologia evoluiu. No entanto, ele não foi concebido para responder se essa tecnologia é segura, confiável ou clinicamente útil. Em outras palavras, o TRL mede progresso, mas não mede qualidade da evidência. Essa distinção é frequentemente negligenciada, gerando uma falsa sensação de robustez em tecnologias que, embora maduras do ponto de vista de desenvolvimento, ainda não foram adequadamente validadas.

Para enfrentar esse problema, propõe-se neste capítulo a integração entre dois modelos complementares. O primeiro é o TRL, que organiza a trajetória de maturidade tecnológica. O segundo é o modelo de três camadas de validação, que estrutura a avaliação da solução em níveis progressivos de complexidade e evidência, abrangendo validação técnica, validação analítica e validação clínica.

A proposta central é simples, mas poderosa. A inovação em saúde não deve ser compreendida como uma linha única de evolução, mas como um processo bidimensional. A tecnologia deve avançar em maturidade ao mesmo tempo em que acumula evidência de validação. O progresso em um eixo não substitui o avanço no outro. Pelo contrário, ambos devem evoluir de forma coordenada e proporcional.

Essa integração permite construir uma leitura mais rigorosa da inovação. Uma tecnologia em estágio avançado de TRL, mas sem validação clínica, deve ser interpretada como potencialmente imatura para uso assistencial. Da mesma forma, uma solução com evidência clínica promissora, mas com baixa robustez técnica, representa um risco operacional. O equilíbrio entre esses dois eixos é o que define, de fato, a maturidade real de uma inovação em saúde.

Para tornar esse modelo tangível, será utilizado ao longo do capítulo o exemplo do FechaFeridas, uma solução voltada para o apoio à avaliação e manejo de feridas crônicas. Esse exemplo permitirá demonstrar, de forma aplicada, como uma mesma tecnologia percorre simultaneamente os eixos de maturidade tecnológica, validação científica e exigência ética.

Ao final, o leitor será capaz de compreender não apenas como desenvolver uma tecnologia em saúde, mas como validar essa tecnologia de forma estruturada, segura e alinhada com as exigências científicas, éticas e regulatórias contemporâneas.

 

BOX 1
Erro clássico na inovação em saúde
1. Desenvolver rapidamente
2. Demonstrar funcionamento técnico
3. Assumir utilidade clínica
4. Ignorar validação progressiva
👉 Resultado: solução tecnicamente sofisticada, clinicamente frágil

.

BOX 2
Ideia central do capítulo
1. TRL mede maturidade
2. Validação mede confiabilidade
3. Impacto clínico exige ambos
👉 Tecnologia sem validação não é inovação, é risco

 

 

 

2. O eixo da maturidade

Mensagem central
👉 TRL mede progresso, não qualidade da evidência

Entendendo o TRL na lógica da saúde

O conceito de Technology Readiness Level (TRL) emerge como uma das tentativas mais bem-sucedidas de organizar o desenvolvimento tecnológico em níveis progressivos de maturidade. Originalmente concebido no contexto aeroespacial, o TRL foi desenhado para responder a uma pergunta objetiva, “quão pronta está essa tecnologia para ser utilizada?”.

Essa pergunta, embora simples, carrega uma potência operacional significativa. Ao decompor o desenvolvimento tecnológico em nove níveis, o TRL permite transformar um processo frequentemente difuso em uma trajetória estruturada, com marcos claros de evolução, desde a descoberta científica inicial até a operação em ambiente real.

No entanto, ao ser transposto para o campo da saúde, o TRL sofre uma transformação silenciosa. Ele passa a ser utilizado não apenas como um indicador de maturidade tecnológica, mas, de forma implícita e muitas vezes equivocada, como um indicativo de qualidade ou até mesmo de segurança clínica. É nesse ponto que reside um dos principais problemas epistemológicos da inovação em saúde contemporânea.

O TRL mede o quanto a tecnologia avançou, mas não mede o quanto ela é confiável, segura ou clinicamente útil.

Essa distinção precisa ser explicitada com rigor.

2.1 A lógica interna do TRL

O TRL organiza o desenvolvimento em três grandes blocos implícitos:

  1. Exploração científica (TRL 1 a 3). Correspondem à fase de descoberta e plausibilidade científica. Aqui, a tecnologia ainda não existe como produto. Existe como princípio, hipótese ou possibilidade teórica.
  2. Desenvolvimento tecnológico (TRL 4 a 6). Representam a transição para o desenvolvimento tecnológico estruturado. Surge o protótipo, a prova de conceito aplicada e os primeiros testes em ambientes controlados ou simulados.
  3. Aplicação operacional (TRL 7 a 9). Correspondem à aplicação em ambiente real. A tecnologia é integrada a sistemas existentes, testada em condições reais e, por fim, consolidada como solução operacional.

Essa divisão não é formalmente descrita na estrutura original, mas emerge claramente quando analisamos a progressão dos níveis. Essa progressão é extremamente eficiente para responder se algo está funcionando enquanto tecnologia. No entanto, ela não responde se essa tecnologia está funcionando enquanto intervenção em saúde.

2.2 A armadilha da maturidade tecnológica

Ao analisar projetos na área da saúde, especialmente aqueles baseados em inteligência artificial, observa-se um padrão recorrente. As soluções que atingem TRL elevados passam a ser interpretadas como prontas para uso clínico, mesmo na ausência de evidência robusta de validação.

Essa interpretação equivale a assumir que: (1) Um sistema que funciona tecnicamente, (2) Que é estável operacionalmente, (3) E que foi testado em ambiente real. É automaticamente uma solução segura, eficaz e clinicamente válida.

Essa inferência é incorreta. O TRL não foi projetado para capturar dimensões como:

  • acurácia clínica
  • impacto em desfechos de saúde
  • redução de erro assistencial
  • segurança do paciente

Ele é um modelo de engenharia, não um modelo de validação clínica.

 

2.3 Releitura do TRL sob a ótica da saúde

Para que o TRL seja útil no contexto da saúde, ele precisa ser reinterpretado. Não como um indicador de suficiência, mas como um indicador de contexto.

Ou seja:

👉 O TRL não diz se você pode usar
👉 Ele diz em que estágio você está para validar

Essa mudança de perspectiva é crítica.

Ela transforma o TRL de um indicador de chegada em um marcador de processo.

 

2.4 Aplicação direta no FechaFeridas

Para tornar essa discussão concreta, consideremos o desenvolvimento do FechaFeridas, um sistema voltado para o apoio à avaliação de feridas crônicas.

Fase inicial, TRL 1–3. O sistema existe como uma ideia estruturada. Define-se o problema clínico, a necessidade de apoio à decisão, a possibilidade de uso de imagens e algoritmos para classificação de lesões. Não há ainda produto funcional. Há uma hipótese de solução. Neste ponto, qualquer tentativa de validação clínica é prematura.

Transição para TRL 4. Surge o primeiro protótipo funcional. O sistema já recebe imagens, processa dados e retorna uma classificação inicial. Testes são realizados em ambiente controlado.

Aqui ocorre um marco fundamental:

👉 entrada na validação técnica

Passa a ser necessário responder:

  • O sistema é estável
  • Os fluxos são rastreáveis
  • Os riscos foram mapeados
  • A interface é compreensível

Sem isso, não há base para avançar.

Evolução para TRL 5–6. O sistema passa a ser testado em ambientes relevantes, com dados mais próximos da realidade clínica. Surge o produto minimamente viável.

Neste momento, emerge uma nova exigência: 👉 validação analítica

Agora não basta funcionar. É necessário demonstrar:

  • consistência do algoritmo
  • reprodutibilidade dos resultados
  • desempenho em diferentes cenários

Essa é a fase em que muitos projetos falham, pois confundem funcionamento com confiabilidade.

 

Avanço para TRL 7–8. O sistema entra no ambiente clínico real. Profissionais utilizam a ferramenta em situações concretas. Decisões passam a ser influenciadas pelo sistema.

Neste ponto, a pergunta muda radicalmente:

👉 Não é mais “funciona?”
👉 É “isso melhora o cuidado?”

Surge a necessidade de:

  • avaliar impacto clínico
  • medir desfechos
  • monitorar segurança
  • analisar interação humano sistema

Aqui se consolida a validação clínica.

Consolidação no TRL 9. O sistema está integrado ao fluxo assistencial. Sua utilização é contínua, estruturada e monitorada. Neste estágio, a validação não termina. Ela muda de natureza.

Sai do campo da pesquisa e entra no campo da:

  • tecnovigilância
  • governança clínica
  • responsabilidade regulatória

 

2.5 Síntese crítica

A análise do TRL no contexto do FechaFeridas revela um ponto central: 👉 A maturidade tecnológica não garante maturidade clínica

Essa afirmação deve ser tratada como um princípio estruturante.

Sem essa distinção, a inovação em saúde corre o risco de produzir soluções que são:

  • tecnologicamente sofisticadas
  • operacionalmente estáveis
  • clinicamente frágeis

 

BOX 3
Releitura estratégica do TRL
1. TRL não mede segurança clínica
2. TRL não mede eficácia
3. TRL não mede impacto assistencial
👉 TRL mede estado de desenvolvimento tecnológico

 

BOX 4
Mudança de paradigma
Antes: 👉 TRL alto = tecnologia pronta
Agora: 👉 TRL alto = tecnologia pronta para ser validada em nível mais exigente

 

 

3. O eixo da validação

Mensagem central
👉 Validação é cumulativa e não negociável

O modelo de três camadas na construção da confiança clínica

Se o TRL organiza o avanço da tecnologia ao longo do tempo, o modelo de três camadas organiza algo ainda mais crítico, a construção da confiança. Enquanto o primeiro responde à pergunta sobre o estágio de desenvolvimento, o segundo responde a uma questão mais exigente, por que essa tecnologia deve ser utilizada em saúde.

Essa distinção não é apenas conceitual, ela é estrutural. Em saúde, não basta que algo funcione. É necessário demonstrar que funciona de forma segura, consistente e clinicamente relevante. A confiança não emerge do desempenho isolado, mas da acumulação progressiva de evidência em diferentes níveis de complexidade. É nesse ponto que o modelo de três camadas se torna não apenas útil, mas necessário.

O modelo propõe que a validação de uma tecnologia em saúde deve ocorrer em três níveis progressivos, interdependentes e cumulativos, a validação técnica, a validação analítica e a validação clínica. Cada uma dessas camadas responde a uma pergunta distinta, mas nenhuma delas pode ser ignorada sem comprometer a integridade da solução.

A validação técnica ocupa a base desse sistema. Ela não se preocupa ainda com o impacto clínico, nem com a acurácia diagnóstica em si. Seu foco está na integridade do sistema enquanto construção tecnológica. Trata-se de verificar se o software foi desenvolvido de forma estruturada, se seus componentes são estáveis, se os fluxos são rastreáveis e se os riscos foram identificados e mitigados. Essa camada se ancora em princípios clássicos da engenharia de software e da segurança em dispositivos médicos, onde a ausência de falhas previsíveis é condição mínima para qualquer avanço posterior.

No contexto do FechaFeridas, essa etapa se materializa no momento em que o sistema deixa de ser uma ideia e passa a ser um artefato funcional. O algoritmo pode ainda ser rudimentar, mas o sistema já recebe dados, processa entradas e produz saídas. A interface precisa ser compreensível, os caminhos de decisão precisam ser auditáveis e os possíveis pontos de falha devem ser antecipados. Não se trata de provar que o sistema acerta, mas de garantir que ele não falha de forma imprevisível. Essa diferença, frequentemente negligenciada, é fundamental.

Superada a camada técnica, emerge a necessidade da validação analítica. Aqui ocorre uma mudança qualitativa importante. O sistema não é mais avaliado apenas como estrutura, mas como mecanismo de interpretação. A pergunta central deixa de ser “o sistema funciona?” e passa a ser “o sistema interpreta corretamente o que recebe?”. Essa transição marca o início da avaliação real do algoritmo.

A validação analítica exige evidência de que o sistema produz resultados consistentes quando submetido a diferentes entradas, que mantém desempenho fora do conjunto de dados utilizado para seu desenvolvimento e que responde de forma previsível a variações do mundo real. É nesse nível que se discutem métricas como acurácia, sensibilidade, especificidade e capacidade de generalização, mas, mais importante do que os valores absolutos dessas métricas, é a sua estabilidade.

No caso do FechaFeridas, essa camada se revela quando o sistema começa a ser testado com imagens reais de feridas, provenientes de diferentes contextos, com variações de iluminação, qualidade e características clínicas. Um algoritmo que performa bem em um conjunto restrito de imagens padronizadas, mas perde desempenho quando exposto à variabilidade do ambiente real, não pode ser considerado validado. A consistência, nesse contexto, é mais relevante do que o desempenho pontual elevado.

A transição para a terceira camada, a validação clínica, representa um novo salto de complexidade. Até esse ponto, o sistema foi avaliado como tecnologia e como instrumento analítico. Agora, ele passa a ser avaliado como intervenção em saúde. A pergunta deixa de ser sobre funcionamento ou interpretação e passa a ser sobre impacto.

A validação clínica exige demonstrar que o uso do sistema modifica a prática assistencial de forma mensurável e, idealmente, benéfica. Isso pode se traduzir em melhora na acurácia diagnóstica, redução de tempo de decisão, diminuição de erros ou impacto direto em desfechos clínicos. O ponto central é que o sistema deixa de ser avaliado isoladamente e passa a ser analisado em interação com o profissional de saúde, com o paciente e com o contexto em que está inserido.

No FechaFeridas, essa etapa se concretiza quando o sistema é utilizado por profissionais em ambiente real, influenciando decisões clínicas. Nesse momento, surgem questões que não poderiam ser antecipadas nas fases anteriores. O usuário confia no sistema? Ele compreende suas recomendações? O sistema reduz a incerteza ou introduz novos tipos de erro? Essas perguntas não pertencem ao domínio da engenharia nem da estatística isoladamente, mas ao campo mais amplo da prática clínica.

Um aspecto fundamental do modelo é sua natureza cumulativa. Não se trata de três caminhos alternativos, mas de três níveis que se apoiam mutuamente. Uma validação clínica robusta não compensa uma base técnica frágil. Da mesma forma, um algoritmo com excelente desempenho analítico não é suficiente se não houver evidência de impacto no mundo real. Cada camada amplia a anterior, mas também depende dela.

Essa estrutura reflete, de forma implícita, a lógica adotada por organismos internacionais na avaliação de tecnologias em saúde, especialmente no contexto de Software as a Medical Device. A necessidade de demonstrar não apenas que um sistema funciona, mas que ele é confiável e clinicamente útil, está no centro das discussões contemporâneas sobre regulação e implementação de inteligência artificial em saúde.

Ao organizar a validação nesses três níveis, o modelo oferece mais do que uma estrutura conceitual. Ele fornece um mapa de progressão da confiança. Cada camada adiciona um tipo distinto de evidência, e a ausência de qualquer uma delas compromete a solidez do conjunto. Essa visão impede que soluções tecnologicamente avançadas sejam prematuramente interpretadas como prontas para uso clínico e, ao mesmo tempo, orienta o desenvolvimento de forma mais segura e estruturada.

BOX 5
A lógica da confiança em três camadas
A confiança em uma tecnologia em saúde não é um atributo único. Ela é construída progressivamente:
1. Na base, a tecnologia precisa ser segura enquanto sistema.
2. No nível intermediário, precisa ser confiável enquanto algoritmo.
3. No topo, precisa ser útil enquanto intervenção clínica.
👉 Sem essa progressão, não há inovação, há apenas sofisticação técnica sem garantia de valor.

 

4. O ponto de ruptura

Mensagem central
👉 Maturidade sem validação gera risco

Por que o TRL sozinho é insuficiente

O Technology Readiness Level é uma ferramenta poderosa para descrever a progressão de uma tecnologia ao longo do seu desenvolvimento. Sua força está em oferecer uma linguagem comum para indicar se uma solução ainda se encontra no plano da hipótese, se já atingiu a condição de protótipo funcional ou se opera em ambiente real. No entanto, exatamente por ser tão eficiente em organizar a trajetória do desenvolvimento, o TRL pode induzir uma interpretação perigosa quando utilizado fora do seu campo próprio. O problema surge quando a maturidade tecnológica passa a ser confundida com prontidão clínica.

Essa confusão constitui o verdadeiro ponto de ruptura do raciocínio sobre inovação em saúde. Até certo ponto, é intuitivo imaginar que uma tecnologia mais madura, mais testada e mais integrada a um ambiente real seja também mais confiável. Em muitos campos da engenharia, essa inferência pode parecer razoável. Em saúde, porém, ela é insuficiente e, em alguns casos, francamente arriscada. Uma tecnologia pode estar avançada em sua trajetória de desenvolvimento e, ainda assim, não ter demonstrado de forma robusta que interpreta corretamente os dados, que melhora a decisão clínica ou que produz benefício real para o paciente.

É justamente aqui que se instala a falsa segurança. O fato de uma solução ter alcançado níveis elevados de TRL pode gerar a impressão de que as principais incertezas já foram superadas. A interface está pronta, o sistema roda com estabilidade, os fluxos estão organizados e a tecnologia já foi exposta a algum tipo de uso real. Tudo isso produz uma aparência de consistência. No entanto, essa aparência pode esconder uma fragilidade central, a ausência de validação proporcional ao nível de maturidade alcançado.

Em saúde, essa assimetria é particularmente grave porque a tecnologia não atua em um vácuo operacional. Ela entra em contato com decisões diagnósticas, terapêuticas e prognósticas. Um sistema aparentemente maduro, mas insuficientemente validado, pode ser incorporado à prática assistencial não porque provou seu valor, mas porque se tornou convincente em sua forma. O risco, portanto, não está apenas em tecnologias claramente imaturas. O risco maior, e mais difícil de perceber, está nas tecnologias que parecem prontas, mas cuja base de evidência ainda é inadequada.

O exemplo do FechaFeridas ajuda a iluminar esse problema. Imagine um sistema que já alcançou um nível elevado de desenvolvimento técnico. Ele recebe imagens, processa dados, apresenta classificações organizadas, gera relatórios e possui uma interface visualmente convincente. Pode até ter sido testado em contextos reais e integrado ao fluxo de trabalho de uma equipe. À primeira vista, tudo sugere maturidade. No entanto, se esse sistema ainda não demonstrou de forma robusta sua capacidade de manter desempenho diante da variabilidade das imagens, das diferenças entre usuários e das condições concretas do ambiente assistencial, então sua maturidade é apenas parcial. Ele funciona, mas isso ainda não significa que ele funciona bem.

Essa distinção entre funcionar e funcionar bem é decisiva. Uma tecnologia funciona quando executa sua tarefa sem colapso operacional. Ela funciona bem quando, além disso, produz saídas consistentes, confiáveis, seguras e clinicamente relevantes. O TRL é capaz de capturar, com relativa precisão, o primeiro aspecto. Ele indica que a tecnologia avançou, que saiu do plano conceitual, que foi prototipada, testada e integrada. Mas ele não capta adequadamente o segundo aspecto. Não informa, por si só, se o algoritmo é robusto, se a interpretação é estável ou se o impacto clínico foi demonstrado.

Essa limitação se torna ainda mais importante em tecnologias baseadas em inteligência artificial, porque nesses casos o desempenho observado em ambientes controlados pode não se reproduzir no mundo real. Um modelo pode apresentar excelente resultado em bases de dados organizadas, curadas e previsíveis, mas falhar quando confrontado com a desordem típica da prática clínica. O aumento do TRL, nesse contexto, pode coexistir com fragilidades profundas na capacidade analítica e clínica do sistema. A maturidade da estrutura não elimina a incerteza sobre o comportamento do núcleo decisório.

Há, portanto, um risco clínico oculto na leitura isolada do TRL. Esse risco não é imediatamente visível porque decorre de uma inferência indevida. Parte-se do fato verdadeiro de que a tecnologia amadureceu e conclui-se, sem prova suficiente, que ela também é segura e útil para o cuidado. Essa passagem lógica é indevida. Entre uma tecnologia avançada e uma tecnologia clinicamente justificável existe um intervalo que só pode ser preenchido por validação técnica, validação analítica e validação clínica.

Esse ponto é crucial porque redefine a forma como o leitor deve interpretar o próprio conceito de progresso em saúde digital. Progredir não é apenas avançar no desenvolvimento. Progredir é reduzir incertezas relevantes. Se a tecnologia cresce em complexidade, mas a incerteza clínica permanece elevada, então o desenvolvimento ocorreu sem consolidação. Há avanço aparente, mas não há amadurecimento completo.

Nesse sentido, o TRL, quando utilizado isoladamente, não é um erro. O erro está em atribuir a ele uma função que ele não possui. O TRL não foi criado para medir segurança do paciente, impacto clínico, robustez analítica ou governança ética. Ele mede a progressão da tecnologia enquanto tecnologia. O problema começa quando ele passa a ser usado como atalho para justificar confiança clínica.

É exatamente essa insuficiência que torna necessária a integração com o modelo de três camadas. A camada técnica protege contra a ilusão de que um sistema funcional já é, por isso, estruturalmente seguro. A camada analítica protege contra a ilusão de que um algoritmo operacional já é, por isso, confiável. A camada clínica protege contra a ilusão de que uma solução utilizada no mundo real já é, por isso, benéfica. Cada camada atua como um mecanismo de contenção contra formas específicas de confiança indevida.

Assim, o ponto de ruptura não é apenas uma crítica ao TRL. É uma crítica à interpretação simplificadora da inovação em saúde. O que se rompe aqui é a suposição de que o desenvolvimento tecnológico, por si só, conduz naturalmente à legitimidade clínica. Em seu lugar, emerge uma visão mais rigorosa, segundo a qual a maturidade só adquire significado prático quando está acompanhada por validação proporcional.

Em termos conceituais, esta seção cumpre um papel fundamental no capítulo. Ela mostra que a integração entre maturidade tecnológica e validação não é uma sofisticação desnecessária, mas uma exigência lógica imposta pela própria natureza do cuidado em saúde. Quando a tecnologia se aproxima do paciente, a ausência de validação deixa de ser uma lacuna metodológica e passa a ser uma fonte concreta de risco.

BOX 6
O erro de interpretação mais perigoso
Uma tecnologia atingir alto TRL não significa que ela já demonstrou:
1. confiabilidade analítica,
2. segurança clínica,
3. ou impacto assistencial.
👉 Significa apenas que ela avançou em seu desenvolvimento tecnológico.

 

BOX 7
A ruptura conceitual do capítulo
O TRL responde: em que estágio a tecnologia está.
Mas a saúde exige outra pergunta: por que essa tecnologia merece confiança.
👉 É nesse intervalo que entram as três camadas de validação.

 

BOX 8
Mensagem central da seção
Maturidade sem validação gera risco.
Não porque a tecnologia seja necessariamente ruim,
mas porque ela pode inspirar uma confiança maior do que a evidência permite.

 

5. A integração

Mensagem central
👉 Inovação real exige evolução simultânea nos dois eixos

 

A matriz TRL × Camadas como modelo de maturidade real

A análise isolada do TRL e do modelo de três camadas de validação revela duas dimensões fundamentais, porém incompletas quando consideradas de forma independente. O TRL descreve a trajetória de desenvolvimento da tecnologia ao longo do tempo, enquanto as camadas de validação estruturam a construção progressiva da confiança. O ponto de convergência entre esses dois modelos não é apenas uma sobreposição conceitual, mas a formação de uma nova estrutura, uma matriz bidimensional de maturidade real.

Essa matriz parte de uma premissa central, frequentemente ignorada na prática. O desenvolvimento tecnológico não é um processo unidimensional. Ele não pode ser reduzido a uma linha crescente de sofisticação técnica. Em saúde, evoluir tecnologicamente sem evoluir simultaneamente na validação equivale a avançar sem consolidar o terreno. A consequência é a produção de soluções instáveis do ponto de vista clínico, ainda que robustas do ponto de vista computacional.

A matriz TRL × Camadas organiza essa complexidade ao introduzir dois eixos independentes, porém interdependentes. No eixo horizontal, posiciona-se o TRL, representando o grau de maturidade tecnológica. No eixo vertical, posicionam-se as camadas de validação, representando o nível de evidência acumulada. O cruzamento desses eixos gera um campo de análise no qual cada tecnologia pode ser situada de forma mais precisa, não apenas pelo estágio em que se encontra, mas pela qualidade da sua sustentação científica.

Essa mudança de perspectiva transforma profundamente a forma de interpretar a inovação. Uma tecnologia em TRL elevado deixa de ser automaticamente considerada madura. Ela passa a ser analisada em função da densidade de validação que sustenta sua posição. Da mesma forma, uma solução com forte evidência clínica, mas ainda em estágio inicial de desenvolvimento, pode ser reconhecida como promissora, porém operacionalmente limitada. A matriz introduz, portanto, uma distinção entre maturidade tecnológica e maturidade validada, sendo esta última a única relevante para a prática em saúde.

No contexto do FechaFeridas, essa matriz permite uma leitura particularmente esclarecedora. Em seus estágios iniciais, o sistema ocupa uma posição nos níveis baixos de TRL e fora das camadas de validação. Trata-se de uma solução conceitual, cuja existência se limita ao plano das hipóteses estruturadas. À medida que o sistema evolui para um protótipo funcional, ele avança horizontalmente na matriz, alcançando níveis intermediários de TRL. No entanto, esse avanço só se torna significativo quando acompanhado de progressão vertical, com a incorporação da validação técnica.

A partir desse ponto, a evolução do sistema deixa de ser linear e passa a exigir um movimento coordenado. Avançar para níveis mais elevados de TRL sem consolidar a validação analítica implica deslocar-se horizontalmente sem sustentação vertical. O sistema torna-se mais complexo, mais integrado e mais próximo do uso real, mas permanece frágil em sua capacidade de interpretar corretamente os dados. Esse descompasso representa uma zona de risco, frequentemente invisível em avaliações tradicionais baseadas apenas em maturidade tecnológica.

O mesmo raciocínio se aplica à transição para a validação clínica. Um sistema que atinge TRL 7 ou 8, sendo utilizado em ambiente assistencial, mas que não demonstrou impacto clínico mensurável, ocupa uma posição elevada no eixo horizontal, porém insuficientemente desenvolvida no eixo vertical. Essa configuração cria uma ilusão de prontidão. A tecnologia está presente no cenário clínico, mas ainda não se justificou como intervenção.

A matriz permite identificar essas zonas críticas com clareza. Ela revela que o risco não está apenas em tecnologias imaturas, mas também em tecnologias assimétricas, isto é, sistemas que evoluíram mais em um eixo do que no outro. A assimetria entre maturidade tecnológica e validação constitui uma das principais fontes de fragilidade na inovação em saúde contemporânea.

Outro aspecto relevante da matriz é sua capacidade de orientar decisões estratégicas. Ao posicionar uma tecnologia nesse espaço bidimensional, torna-se possível identificar qual é o próximo passo lógico de desenvolvimento. Um sistema com base técnica consolidada, mas sem validação analítica, não deve avançar diretamente para estudos clínicos. Da mesma forma, uma solução com bom desempenho analítico, mas ainda sem robustez técnica, não deve ser exposta ao ambiente assistencial. A matriz funciona, portanto, como um instrumento de governança do desenvolvimento, orientando a sequência adequada de evolução.

Essa lógica introduz uma noção importante, a de que cada avanço no eixo do TRL deve ser acompanhado por um aumento proporcional na exigência de validação. Não se trata de uma relação opcional, mas de uma condição estrutural para a segurança e a efetividade da inovação em saúde. O crescimento horizontal exige densificação vertical. Sem essa correspondência, o sistema se expande sem consolidar sua base.

A integração entre TRL e camadas de validação também permite reinterpretar o conceito de maturidade final. Tradicionalmente, o TRL 9 é considerado o estágio máximo de desenvolvimento, caracterizado pela operação da tecnologia em ambiente real. No entanto, à luz da matriz, o TRL 9 só representa maturidade plena quando associado à consolidação das três camadas de validação. Uma tecnologia que atinge TRL 9 sem validação clínica robusta não pode ser considerada madura, apenas operacional.

Essa distinção é particularmente relevante em um cenário no qual soluções baseadas em inteligência artificial podem ser rapidamente implementadas em larga escala. A facilidade de distribuição digital cria a possibilidade de difusão de tecnologias ainda não plenamente validadas. A matriz TRL × Camadas atua como um mecanismo de contenção conceitual, impedindo que a presença no ambiente real seja confundida com evidência de benefício.

Ao final, a matriz não deve ser interpretada apenas como uma ferramenta analítica, mas como um modelo normativo. Ela estabelece um padrão de como a inovação em saúde deve ocorrer, não apenas de como ela ocorre na prática. Ao exigir progressão simultânea em maturidade tecnológica e validação, o modelo redefine o próprio conceito de inovação. Inovar não é apenas criar algo novo, mas criar algo que seja tecnicamente sólido, analiticamente confiável e clinicamente relevante.

BOX 9
Princípio da maturidade real
Uma tecnologia só pode ser considerada madura quando:
1. Ela é tecnicamente estável,
2. analiticamente confiável,
3. clinicamente validada.
👉 Qualquer ausência transforma maturidade em aparência de maturidade

 

BOX 10
Risco estrutural da inovação em saúde
O maior risco não está na tecnologia imatura.
Está na tecnologia que parece madura, mas não é validada.
👉 Isso produz confiança indevida, e confiança indevida em saúde é risco clínico.

6. Leitura progressiva da matriz

Mensagem central
👉 Cada avanço de TRL exige aumento proporcional de evidência

Do TRL 1 ao TRL 9 sob a lógica da validação e da ética

A principal contribuição da matriz TRL × Camadas não está apenas na sua capacidade de descrever o estado de uma tecnologia, mas em permitir uma leitura dinâmica do seu percurso. Ao percorrer os níveis do TRL sob a ótica das camadas de validação, torna-se possível compreender que cada avanço tecnológico impõe uma exigência proporcional de evidência e uma expansão progressiva da responsabilidade ética. Essa leitura rompe com a ideia de que o desenvolvimento tecnológico é uma sequência linear de etapas independentes. Em seu lugar, propõe-se um modelo no qual cada transição representa uma mudança qualitativa na natureza da tecnologia, no tipo de evidência exigida e no nível de risco envolvido.

 

TRL 1 a 3 – O domínio da plausibilidade sem validação

Nos níveis iniciais, a tecnologia existe como possibilidade estruturada. O foco está na compreensão do problema, na formulação da hipótese e na exploração de princípios científicos. No caso do FechaFeridas, esse estágio corresponde ao momento em que se reconhece a necessidade de apoio à avaliação de feridas crônicas e se concebe a ideia de utilizar imagens e algoritmos como ferramenta de apoio à decisão.

Neste ponto, não há ainda sistema funcional, nem algoritmo testável, nem interação com usuários. Consequentemente, não há validação técnica, analítica ou clínica. Trata-se de um espaço pré-validatório, no qual o erro mais comum é tentar antecipar conclusões que ainda não podem ser sustentadas.

Do ponto de vista ético, o risco é inexistente, pois não há envolvimento de seres humanos nem utilização de dados sensíveis. No entanto, já se estabelece uma responsabilidade conceitual, a de definir corretamente o problema e evitar promessas implícitas que não possam ser cumpridas nas etapas posteriores.

 

TRL 4 – A entrada na validação e o surgimento da responsabilidade técnica

A transição para o TRL 4 marca um ponto de inflexão. A tecnologia deixa de ser apenas uma hipótese e passa a existir como protótipo funcional. No FechaFeridas, isso se traduz na construção de um sistema capaz de receber dados, processá-los e gerar uma saída interpretável.

É neste momento que se inicia formalmente a validação técnica. A preocupação central não está na acurácia do sistema, mas na sua integridade estrutural. O sistema precisa ser estável, seus fluxos precisam ser compreensíveis e os riscos previsíveis devem ser identificados e mitigados. Surge, portanto, uma nova dimensão de responsabilidade, a responsabilidade de garantir que o sistema não introduza falhas imprevisíveis.

Do ponto de vista ético, essa fase pode parecer ainda distante do cuidado direto, mas já envolve interação com especialistas, testes estruturados e, eventualmente, coleta de julgamentos técnicos. Isso desloca a tecnologia para uma zona de atenção ética inicial, na qual a formalização do processo começa a ser necessária.

 

TRL 5 e 6 – A transição para a confiabilidade e a emergência da validação analítica

À medida que a tecnologia avança para os níveis 5 e 6, ocorre uma mudança substancial em sua natureza. O sistema deixa de ser apenas funcional e passa a ser testado em condições que simulam a realidade. No caso do FechaFeridas, isso significa utilizar dados reais, com todas as imperfeições que caracterizam o ambiente clínico, como variações de imagem, iluminação e contexto.

Neste estágio, a validação técnica já não é suficiente. Surge a necessidade de demonstrar que o sistema é analiticamente confiável. A questão central passa a ser a consistência da interpretação. O algoritmo deve produzir resultados estáveis, manter desempenho em diferentes cenários e demonstrar capacidade de generalização.

Essa fase representa o verdadeiro teste da robustez da solução. Muitos sistemas que funcionam bem em ambientes controlados falham quando expostos à variabilidade do mundo real. A validação analítica atua justamente como filtro para essas fragilidades ocultas.

Do ponto de vista ético, ocorre uma transformação importante. O envolvimento de dados reais e, potencialmente, de participantes humanos torna obrigatória a submissão a instâncias de avaliação ética. O risco deixa de ser teórico e passa a ser concreto, ainda que controlado. A responsabilidade do desenvolvedor se expande, exigindo transparência, consentimento e monitoramento.

 

TRL 7 e 8 – A entrada no mundo real e a exigência de validação clínica

A transição para os níveis 7 e 8 representa o momento mais crítico da trajetória. A tecnologia deixa o ambiente de teste e passa a ser utilizada em contexto assistencial real. No FechaFeridas, isso significa que profissionais de saúde começam a utilizar o sistema como apoio à decisão, influenciando diretamente o cuidado prestado ao paciente.

Neste ponto, a pergunta central muda de forma definitiva. Não se trata mais de saber se o sistema funciona ou se interpreta corretamente os dados. Trata-se de determinar se ele melhora a prática clínica. Surge, então, a necessidade de validação clínica.

A validação clínica exige evidência de impacto. O sistema deve demonstrar que contribui para decisões mais adequadas, reduz erros, melhora fluxos ou impacta desfechos. Mais do que métricas isoladas, o que se busca é a integração do sistema no ecossistema clínico de forma segura e eficaz.

Essa fase também revela um novo tipo de complexidade. A interação entre o sistema e o usuário torna-se central. Um algoritmo perfeito, mas mal compreendido, pode gerar erros. Da mesma forma, um sistema que altera o comportamento do profissional sem controle adequado pode introduzir riscos não previstos.

Do ponto de vista ético, essa é uma fase de alta densidade. O risco é direto, a responsabilidade é ampliada e a necessidade de supervisão é máxima. A avaliação ética torna-se mais rigorosa, frequentemente envolvendo instâncias de maior complexidade e exigindo documentação robusta.

TRL 9 – A consolidação e a transição para a responsabilidade contínua

No TRL 9, a tecnologia atinge sua forma operacional plena. O sistema está integrado ao fluxo assistencial, sendo utilizado de forma contínua e em larga escala. No entanto, essa consolidação não representa o fim do processo de validação. Ela representa uma mudança de regime.

A validação deixa de ser predominantemente prospectiva e passa a ser contínua. Surge a necessidade de monitoramento permanente, análise de desempenho em longo prazo, identificação de eventos adversos e adaptação a novos contextos. O sistema entra no domínio da tecnovigilância e da governança clínica.

No caso do FechaFeridas, isso implica acompanhar seu desempenho ao longo do tempo, identificar possíveis desvios, atualizar modelos e garantir que o sistema continue alinhado com as melhores práticas clínicas e regulatórias.

Do ponto de vista ético, ocorre uma transição importante. A tecnologia deixa o campo da ética em pesquisa e passa a ser regulada pela ética profissional, pelas normas sanitárias e pela legislação de responsabilidade civil. A responsabilidade não diminui, ela se transforma. Deixa de ser episódica e passa a ser contínua.

Em resumo, a leitura progressiva da matriz revela um padrão claro. Cada avanço no TRL implica uma ampliação simultânea em três dimensões, a complexidade da tecnologia, a exigência de validação e o nível de responsabilidade ética. Esse crescimento não é opcional nem arbitrário. Ele reflete a própria natureza da inovação em saúde, na qual o aumento do poder de intervenção traz consigo um aumento proporcional do potencial de dano. Validar não é apenas demonstrar eficácia, é controlar risco. A matriz TRL × Camadas, quando percorrida dessa forma, deixa de ser um modelo estático e passa a funcionar como um roteiro de desenvolvimento responsável. Ela orienta não apenas onde a tecnologia está, mas o que precisa ser feito para que ela avance de forma segura e legítima.

BOX 12
Princípio da progressão responsável
Cada avanço no TRL exige:
1. mais evidência,
2. mais controle,
3. mais responsabilidade.
👉 Crescer tecnologicamente sem crescer em validação é ampliar risco.

 

BOX 13
A tríade da evolução em saúde
Ao longo da trajetória, três dimensões evoluem juntas:
1. Tecnologia,
2. Validação,
3. Ética.
👉 Se uma delas fica para trás, a inovação se torna instável.

 

 

7. Integração com ética, regulação e tomada de decisão prática

Mensagem central
👉 Validação não é só técnica, é ética

Da validação científica à responsabilidade institucional

A integração entre maturidade tecnológica, validação progressiva e exigência ética não é apenas desejável, ela é inevitável quando a tecnologia se aproxima do cuidado em saúde. À medida que uma solução avança na matriz TRL × Camadas, ela deixa de ser um objeto técnico e passa a ser um agente com potencial de influenciar decisões clínicas, afetar desfechos e, em última instância, impactar vidas humanas.

Essa transição exige uma mudança de paradigma. O desenvolvimento tecnológico não pode mais ser conduzido apenas sob a lógica da eficiência ou da inovação. Ele passa a ser regido por uma lógica de responsabilidade ampliada, na qual cada avanço implica novas obrigações éticas, regulatórias e institucionais.

 

A ética como eixo transversal, não como etapa

Um dos equívocos mais frequentes na condução de projetos em saúde é tratar a ética como uma etapa pontual, frequentemente associada apenas ao momento da submissão ao Comitê de Ética em Pesquisa. Essa visão fragmentada ignora o fato de que a ética acompanha toda a trajetória da tecnologia, desde a definição do problema até sua utilização em larga escala.

Na leitura da matriz, a ética se comporta como um eixo transversal, cuja intensidade aumenta progressivamente. Nos níveis iniciais de TRL, a responsabilidade ética é predominantemente conceitual, relacionada à definição adequada do problema e à honestidade na comunicação das possibilidades da solução. À medida que o sistema evolui e passa a interagir com dados reais e participantes humanos, essa responsabilidade se torna formal, exigindo consentimento, transparência e controle de risco.

Quando a tecnologia atinge os níveis mais elevados e passa a ser utilizada em ambiente assistencial, a ética assume sua forma mais complexa. Ela deixa de ser apenas um requisito de pesquisa e passa a integrar a prática profissional, envolvendo princípios como beneficência, não maleficência, autonomia e justiça. Nesse ponto, o comportamento do sistema não pode ser analisado isoladamente, mas em interação com o profissional, com o paciente e com o contexto institucional.

 

A transição ética ao longo da matriz

A progressão ao longo do TRL pode ser compreendida também como uma progressão de regimes éticos. Nos níveis iniciais, a tecnologia se desenvolve fora do campo da pesquisa envolvendo seres humanos, não havendo necessidade de submissão a sistemas de avaliação ética. No entanto, essa condição se altera rapidamente quando a tecnologia passa a incorporar dados reais ou a envolver interação com especialistas de forma estruturada.

A partir do momento em que há coleta sistematizada de dados, mesmo que não haja intervenção direta sobre pacientes, surge a necessidade de apreciação por Comitê de Ética. Essa exigência não decorre apenas do risco físico, mas da necessidade de proteger a integridade dos participantes e garantir a legitimidade do processo de produção de conhecimento.

Nos níveis intermediários, quando a tecnologia começa a ser testada em condições mais próximas da realidade, o risco torna-se mais concreto. A submissão ao sistema CEP SINEP passa a ser obrigatória, e o Termo de Consentimento Livre e Esclarecido assume papel central como instrumento de comunicação ética.

Nos níveis mais avançados, especialmente em TRL 7 e 8, a complexidade ética se intensifica. A tecnologia passa a interferir diretamente na prática assistencial, exigindo não apenas aprovação ética, mas monitoramento contínuo, gestão de risco e, em muitos casos, avaliação em instâncias de maior abrangência.

Por fim, no TRL 9, ocorre uma transição de regime. A tecnologia deixa de estar sob o domínio da ética em pesquisa e passa a ser regida pela ética profissional e pelas normas sanitárias. A responsabilidade não desaparece, ela se transforma em responsabilidade contínua, exigindo vigilância permanente.

Regulação, da validação à autorização de uso

A validação científica, embora necessária, não é suficiente para a utilização de uma tecnologia em saúde. É necessário que essa tecnologia seja reconhecida por instâncias regulatórias como adequada para uso. Essa transição da validação para a autorização representa um momento crítico, no qual evidência científica se converte em decisão institucional.

No contexto brasileiro, essa etapa envolve a atuação de órgãos reguladores como a ANVISA, que avalia a segurança e a eficácia de dispositivos médicos, incluindo softwares. A classificação da tecnologia, o nível de risco associado e a robustez das evidências apresentadas determinam o tipo de exigência regulatória.

A matriz TRL × Camadas oferece uma contribuição relevante nesse processo ao permitir que o desenvolvedor compreenda, de forma antecipada, qual é o nível de evidência necessário para cada estágio de desenvolvimento. Uma tecnologia em níveis intermediários de TRL, ainda sem validação clínica robusta, dificilmente atenderá aos requisitos para autorização de uso amplo. Por outro lado, uma solução que percorreu adequadamente as três camadas de validação estará mais bem posicionada para enfrentar o processo regulatório.

Essa antecipação reduz incertezas, evita retrabalho e aumenta a probabilidade de sucesso na transição para o mercado.

LGPD e governança de dados, a base invisível da confiança

No contexto das tecnologias digitais em saúde, especialmente aquelas baseadas em dados e inteligência artificial, a governança da informação assume papel central. A Lei Geral de Proteção de Dados introduz uma camada adicional de responsabilidade, que atravessa todas as etapas da matriz.

Desde os níveis iniciais em que dados são coletados ou simulados, até os estágios mais avançados em que sistemas operam em larga escala, é necessário garantir que o tratamento das informações ocorra de forma lícita, transparente e segura. Isso envolve não apenas a proteção contra acesso indevido, mas também a definição clara de finalidade, a minimização de dados e o respeito aos direitos dos titulares.

No FechaFeridas, isso se traduz na necessidade de estruturar fluxos de dados que garantam anonimização quando possível, rastreabilidade de uso, controle de acesso e clareza sobre como as informações são utilizadas. A confiança do sistema não depende apenas do seu desempenho clínico, mas também da forma como ele lida com os dados que o alimentam.

 

Tomada de decisão prática, o uso da matriz como ferramenta

A integração entre ética, regulação e validação ganha seu valor máximo quando utilizada como instrumento de tomada de decisão. A matriz TRL × Camadas permite que pesquisadores, desenvolvedores e gestores respondam a perguntas críticas de forma estruturada.

Ao posicionar uma tecnologia na matriz, torna-se possível identificar não apenas seu estágio atual, mas o que falta para que ela avance de forma segura. Essa leitura orienta decisões como iniciar ou não um estudo clínico, submeter um projeto ao CEP, buscar aprovação regulatória ou implementar a solução em ambiente assistencial.

No caso do FechaFeridas, a matriz pode ser utilizada para definir o momento adequado de cada transição. Antes de expor o sistema ao ambiente clínico, é necessário garantir que a validação analítica esteja consolidada. Antes de buscar autorização regulatória, é fundamental que exista evidência clínica robusta. Antes de escalar o uso, é indispensável que haja governança de dados estruturada. Essa abordagem reduz decisões baseadas em intuição ou pressão externa e substitui por um modelo orientado por evidência e responsabilidade.

Assim, a integração entre validação, ética e regulação revela que a inovação em saúde não é apenas um processo técnico, mas um processo institucional. Cada avanço tecnológico amplia o potencial de impacto e, simultaneamente, o nível de responsabilidade. A matriz TRL × Camadas, quando incorporada a essa lógica, deixa de ser apenas um instrumento de análise e passa a funcionar como um sistema de orientação para a prática responsável. Ela conecta desenvolvimento, validação, proteção do paciente e conformidade regulatória em uma única estrutura coerente.

 

BOX 14
Princípio da responsabilidade progressiva
Quanto maior o poder de intervenção da tecnologia, maior deve ser:
1. a qualidade da evidência,
2. o controle ético,
3. e a exigência regulatória.
👉 Em saúde, capacidade sem controle é risco.

 

BOX 15
Decisão orientada pela matriz
Antes de avançar, pergunte:
1. Essa tecnologia está madura o suficiente?
2. Está validada o suficiente?
3. Está eticamente autorizada?
4. Está regulatoriamente adequada?
👉 Se qualquer resposta for negativa, o avanço é prematuro.

8. Aplicação prática

Mensagem central:
👉 O modelo funciona no mundo real

Exemplo estruturado, o modelo em funcionamento no mundo real

A utilidade de um modelo conceitual em saúde não se mede apenas pela sua coerência teórica, mas pela sua capacidade de organizar decisões reais em contextos complexos. A matriz TRL × Camadas atinge seu valor máximo quando aplicada a um caso concreto, no qual as tensões entre desenvolvimento tecnológico, validação e exigência ética se manifestam de forma clara. Nesse sentido, o sistema FechaFeridas oferece um exemplo particularmente adequado, pois combina elementos de software clínico, interpretação baseada em dados e interação direta com o cuidado.

Ao observar a trajetória do FechaFeridas dentro da matriz, torna-se possível compreender como uma mesma tecnologia percorre simultaneamente dois eixos, o da maturidade tecnológica e o da validação progressiva, sendo continuamente reconfigurada à medida que avança.

Nos níveis iniciais, correspondentes ao TRL 1 a 3, o sistema existe como uma hipótese estruturada de solução. Identifica-se o problema clínico, a variabilidade na avaliação de feridas crônicas, a necessidade de padronização e apoio à decisão. Nesse momento, a tecnologia ainda não existe como sistema funcional. Não há interface, não há algoritmo operacional, não há interação com usuários. Trata-se de um espaço de plausibilidade científica e conceitual, no qual o principal risco não é clínico, mas epistemológico, definir mal o problema e comprometer toda a trajetória subsequente.

A transição para o TRL 4 marca o surgimento do sistema como artefato. O FechaFeridas passa a receber dados, processar imagens e produzir classificações iniciais. Ainda que de forma rudimentar, há um fluxo funcional. É nesse ponto que se inicia a validação técnica, com foco na integridade do sistema. A preocupação central não está na precisão da classificação, mas na estabilidade do funcionamento, na rastreabilidade dos processos e na identificação de riscos previsíveis. O sistema deixa de ser apenas uma ideia e passa a ser uma estrutura que pode falhar, e, portanto, precisa ser controlada.

À medida que o sistema evolui para os níveis TRL 5 e 6, ele passa a ser testado em condições mais próximas da realidade. Imagens reais são utilizadas, com todas as imperfeições do ambiente clínico. Surge o produto minimamente viável, e com ele a necessidade de demonstrar que o sistema não apenas funciona, mas interpreta corretamente o que recebe. Aqui se consolida a validação analítica. O algoritmo precisa demonstrar consistência, manter desempenho diante de variações e evitar degradação significativa quando exposto a dados fora do conjunto inicial de desenvolvimento. Este é o ponto em que muitos sistemas revelam fragilidades ocultas, pois o ambiente real impõe uma variabilidade que não pode ser completamente simulada.

A transição para os níveis TRL 7 e 8 representa um momento crítico. O FechaFeridas passa a ser utilizado em ambiente assistencial real, influenciando decisões clínicas. O sistema deixa de ser apenas um objeto de teste e passa a ser um elemento ativo no cuidado. Nesse momento, a pergunta central se transforma. Não se trata mais de saber se o sistema funciona ou se interpreta corretamente os dados. Trata-se de determinar se ele melhora a prática clínica. Surge, então, a exigência de validação clínica.

A validação clínica, nesse contexto, envolve múltiplas dimensões. É necessário avaliar se o sistema reduz a variabilidade entre avaliadores, se melhora a acurácia diagnóstica, se contribui para decisões mais rápidas ou mais seguras e se não introduz novos tipos de erro. Além disso, a interação entre o sistema e o profissional passa a ser um elemento central. Um sistema tecnicamente correto pode falhar se for mal compreendido ou mal utilizado. A validação clínica, portanto, não se limita ao desempenho do algoritmo, mas inclui o comportamento do sistema dentro do ecossistema assistencial.

No TRL 9, o FechaFeridas atinge sua forma operacional plena. Está integrado ao fluxo assistencial, sendo utilizado de forma contínua. No entanto, essa consolidação não representa o fim da trajetória. Representa uma mudança de natureza. A validação deixa de ser episódica e passa a ser contínua, exigindo monitoramento, atualização e governança permanente. O sistema entra no domínio da tecnovigilância, onde seu desempenho precisa ser acompanhado ao longo do tempo, em diferentes contextos e populações.

Ao percorrer essa trajetória, torna-se evidente que o avanço do FechaFeridas não pode ser descrito apenas como um aumento de complexidade tecnológica. Trata-se de um processo de densificação progressiva de evidência e responsabilidade. Cada avanço no TRL exige não apenas mais desenvolvimento, mas mais validação, mais controle e maior rigor ético.

Essa leitura torna tangível a proposta do capítulo. A matriz não é uma abstração. Ela descreve um caminho real, percorrido por tecnologias que transitam entre a ideia e a prática clínica. Mais do que isso, ela evidencia que o sucesso de uma inovação em saúde não depende apenas da sua capacidade de funcionar, mas da sua capacidade de justificar, com evidência, a confiança que se deposita nela.

BOX 16
Mensagem central da aplicação prática
O modelo não é apenas teórico.
Ele descreve como uma tecnologia real evolui,
como surgem novas exigências em cada etapa,
e como o equilíbrio entre maturidade e validação define o sucesso. 👉 O modelo funciona no mundo real.

9. Versão operacional

Mensagem central
👉 O modelo pode ser executado

Da teoria ao sistema, transformando o modelo em ferramenta

A consolidação de um modelo conceitual em saúde depende da sua capacidade de ser traduzido em instrumentos operacionais. Sem essa tradução, mesmo estruturas teoricamente robustas tendem a permanecer no campo da abstração, com impacto limitado sobre a prática. A matriz TRL × Camadas, ao organizar o desenvolvimento tecnológico e a validação de forma integrada, oferece uma base particularmente adequada para essa transformação.

O primeiro passo dessa operacionalização consiste na conversão das camadas de validação em critérios observáveis e verificáveis. A validação técnica pode ser traduzida em itens como documentação da arquitetura, registro de requisitos, controle de versões, análise estruturada de risco e testes de funcionamento. A validação analítica pode ser expressa em termos de desempenho, consistência, generalização e estabilidade do algoritmo. A validação clínica pode ser operacionalizada por meio de evidências de impacto, estudos em ambiente real e análise da interação entre sistema e usuário.

Essa tradução permite a construção de checklists estruturados, que funcionam como guias de decisão ao longo do desenvolvimento. Esses checklists não devem ser interpretados como listas rígidas de verificação, mas como instrumentos de reflexão orientada, que ajudam a identificar lacunas, priorizar ações e evitar avanços prematuros.

Além dos checklists, a matriz permite a definição de indicadores de maturidade validada. Esses indicadores não se limitam ao posicionamento no TRL, mas incorporam a densidade de validação em cada camada. Um sistema pode ser classificado, por exemplo, como tecnicamente consolidado, analiticamente em desenvolvimento e clinicamente não validado. Essa classificação mais granular permite uma leitura mais precisa do estado da tecnologia e orienta decisões com maior segurança.

No contexto do ensino, essa estrutura oferece uma oportunidade valiosa. Estudantes podem ser expostos não apenas ao desenvolvimento de soluções, mas à lógica da validação progressiva. A matriz funciona como ferramenta pedagógica para demonstrar que a inovação em saúde exige não apenas criatividade, mas rigor metodológico e responsabilidade ética. Casos como o FechaFeridas podem ser utilizados para simular decisões em diferentes estágios, estimulando o raciocínio crítico.

No ambiente de startups, a matriz assume uma função estratégica. Ela permite alinhar desenvolvimento tecnológico com expectativas regulatórias e de mercado. Ao identificar precocemente a necessidade de validação analítica e clínica, reduz-se o risco de investir recursos em soluções que não serão sustentáveis do ponto de vista regulatório. A matriz atua, portanto, como instrumento de gestão de risco e priorização de investimento.

Na pesquisa científica, a matriz contribui para a organização do percurso investigativo. Ela orienta a sequência de estudos, evitando a realização prematura de ensaios clínicos sem base técnica ou analítica adequada. Além disso, facilita a comunicação dos resultados, pois oferece uma linguagem estruturada para descrever o estágio de desenvolvimento e o nível de evidência alcançado.

Essa convergência entre ensino, inovação e pesquisa revela o potencial do modelo como um framework integrador. Ele não apenas organiza o desenvolvimento de tecnologias, mas também articula diferentes atores e contextos em torno de uma lógica comum. Ao final, a versão operacional da matriz transforma o modelo em algo mais do que uma ferramenta de análise. Ela o converte em um sistema de decisão, capaz de orientar ações concretas, reduzir incertezas e aumentar a segurança do processo de inovação.

BOX 17
Mensagem central da versão operacional
O modelo não é apenas uma forma de pensar.
Ele pode ser convertido em:
1. instrumento de avaliação,
2. ferramenta de decisão,
3. estrutura de ensino,
4. e base para produtos digitais. 👉 O modelo pode ser executado.

 

10. Limites, implicações e redefinição do conceito de inovação em saúde

Mensagem central
👉 Inovação em saúde não é alcançar o estágio final de desenvolvimento, é atingir o ponto em que a tecnologia se torna legitimamente confiável.

 

A proposta de integração entre o Technology Readiness Level e o modelo de três camadas de validação oferece uma estrutura robusta para compreender e orientar o desenvolvimento de tecnologias em saúde. No entanto, como todo modelo, ela não está isenta de limitações. Reconhecê-las não enfraquece a proposta, ao contrário, amplia sua aplicabilidade e evita interpretações simplificadoras.

Uma primeira limitação reside na própria natureza da matriz. Ao organizar o desenvolvimento em dois eixos, corre-se o risco de induzir uma leitura excessivamente estruturada de um processo que, na prática, é frequentemente não linear. Tecnologias podem avançar de forma desigual, sofrer retrocessos, demandar revisões e, em muitos casos, necessitar de retornos a etapas anteriores para correção de falhas identificadas tardiamente. A matriz não elimina essa dinâmica, mas pode, se utilizada de forma rígida, mascarar a complexidade real do processo.

Outro ponto relevante diz respeito à heterogeneidade das tecnologias em saúde. Nem todas as soluções seguem o mesmo padrão de desenvolvimento, nem demandam o mesmo tipo de evidência. Dispositivos de baixo risco, sistemas de apoio administrativo ou ferramentas de educação em saúde podem não exigir o mesmo nível de validação clínica que soluções diretamente envolvidas na tomada de decisão diagnóstica ou terapêutica. A aplicação da matriz, portanto, deve ser modulada pelo nível de risco e pelo impacto potencial da tecnologia.

Há ainda o desafio da operacionalização. Embora o modelo ofereça uma estrutura conceitual clara, sua implementação na prática exige tradução em ferramentas, indicadores e processos institucionais. Sem essa tradução, há o risco de que a matriz permaneça no campo teórico, sem influenciar de fato a tomada de decisão. A construção de checklists, sistemas de monitoramento e plataformas digitais, como proposto ao longo deste capítulo, é essencial para transformar o modelo em instrumento efetivo de governança.

Apesar dessas limitações, a principal contribuição da matriz não está na sua capacidade de descrever o desenvolvimento tecnológico, mas em sua capacidade de redefinir o conceito de maturidade em saúde. Tradicionalmente, maturidade tem sido associada ao estágio final do desenvolvimento tecnológico, frequentemente representado pelo TRL 9. No entanto, essa associação revela-se insuficiente quando analisada à luz das exigências clínicas, éticas e regulatórias.

Uma tecnologia pode atingir o mais alto nível de maturidade operacional e, ainda assim, carecer de validação clínica robusta. Pode estar amplamente implementada, ser tecnicamente sofisticada e operacionalmente estável, mas não ter demonstrado impacto positivo no cuidado. Nesse cenário, o conceito clássico de maturidade se torna inadequado. Ele descreve presença, mas não justifica uso.

A matriz TRL × Camadas propõe uma mudança fundamental. Maturidade deixa de ser entendida como estágio final de desenvolvimento e passa a ser compreendida como alinhamento entre desenvolvimento e validação. Uma tecnologia só pode ser considerada madura quando sua posição no eixo do TRL é sustentada por uma densidade equivalente no eixo da validação.

Essa redefinição tem implicações profundas. Ela desloca o foco da inovação do “fazer funcionar” para o “fazer funcionar com segurança, consistência e impacto”. Ao fazer isso, aproxima a lógica da inovação da lógica da prática clínica, na qual decisões não são tomadas com base apenas em possibilidade, mas em evidência.

Outro aspecto relevante é a introdução da ideia de assimetria de maturidade. A matriz permite identificar tecnologias que evoluíram de forma desequilibrada, avançando rapidamente em maturidade tecnológica, mas sem validação correspondente. Essas tecnologias ocupam posições elevadas no eixo horizontal, mas permanecem frágeis no eixo vertical. Essa assimetria é particularmente perigosa, pois gera uma aparência de robustez que pode induzir confiança indevida.

A identificação dessa assimetria constitui uma das principais contribuições práticas do modelo. Ela permite antecipar riscos, orientar correções e evitar a implementação prematura de soluções que ainda não foram adequadamente validadas. Nesse sentido, a matriz não apenas descreve o estado da tecnologia, mas atua como mecanismo de prevenção de erro sistêmico.

A integração com o exemplo do FechaFeridas reforça essa perspectiva. Ao longo do capítulo, observou-se que o sistema, em cada estágio de desenvolvimento, exige não apenas avanços tecnológicos, mas também a incorporação de novos níveis de validação e de responsabilidade ética. O que define a qualidade da trajetória não é a velocidade com que se avança no TRL, mas a capacidade de manter equilíbrio entre maturidade, validação e governança.

Essa visão conduz a uma redefinição mais ampla do próprio conceito de inovação em saúde. Inovar não é apenas introduzir uma nova tecnologia ou melhorar uma solução existente. Inovar, no contexto da saúde, é produzir uma intervenção que seja tecnicamente sólida, analiticamente confiável, clinicamente relevante e eticamente justificada. Qualquer inovação que falhe em um desses pilares deve ser considerada incompleta.

Ao final, a matriz TRL × Camadas se apresenta não apenas como uma ferramenta analítica, mas como um princípio orientador. Ela estabelece um padrão de desenvolvimento que privilegia segurança, evidência e responsabilidade, sem inviabilizar a criatividade e o avanço tecnológico. Pelo contrário, ao estruturar o caminho, ela reduz incertezas e aumenta a probabilidade de que a inovação produza valor real.

 

11. Considerações Finais

Mensagem final:
👉 Não basta evoluir tecnologicamente. É preciso validar progressivamente.

A trajetória da inovação em saúde não pode mais ser compreendida como uma sequência linear de avanços tecnológicos. A complexidade do cuidado, a sensibilidade dos desfechos clínicos e a responsabilidade ética envolvida exigem um modelo mais sofisticado, capaz de integrar desenvolvimento, validação e governança em uma única estrutura coerente.

A integração entre o Technology Readiness Level e o modelo de três camadas de validação oferece essa estrutura. Ao articular maturidade tecnológica com progressão de evidência, a matriz proposta redefine o conceito de prontidão em saúde. Não se trata mais de saber se a tecnologia está pronta para ser usada, mas se ela está pronta para ser confiável. Essa mudança de perspectiva é fundamental em um cenário marcado pela rápida expansão de tecnologias digitais e inteligência artificial. A facilidade de desenvolvimento e distribuição não pode ser confundida com legitimidade clínica. A presença no ambiente assistencial não substitui a necessidade de evidência. A sofisticação técnica não compensa a ausência de validação.

A matriz TRL × Camadas oferece um caminho para enfrentar esse desafio. Ela orienta o desenvolvimento de forma progressiva, identifica zonas de risco, estrutura a tomada de decisão e integra dimensões frequentemente tratadas de forma isolada. Ao fazer isso, contribui para a construção de uma inovação mais segura, mais consistente e mais alinhada com os princípios fundamentais da prática em saúde.

Em última instância, a proposta aqui apresentada não busca apenas melhorar o desenvolvimento de tecnologias, mas contribuir para a construção de uma cultura de inovação baseada em responsabilidade, evidência e impacto real.

 

BOX 18
Síntese final do capítulo
Tecnologia sem validação é apenas possibilidade.
Validação sem impacto é apenas evidência.
Impacto sem controle é risco.
👉 Inovação em saúde exige equilíbrio entre maturidade, validação e responsabilidade.

 

Fontes

1. IMDRF – SaMD: Clinical Evaluation (2017)

  • IMDRF. Software as a Medical Device (SaMD): Clinical Evaluation. 2017.
  • 🔗 https://www.imdrf.org/documents/software-medical-device-samd-clinical-evaluation
  • Este é o documento mais importante para sustentar o seu modelo. Ele estabelece explicitamente a lógica de avaliação em três dimensões, validade clínica, validação analítica e associação científica, que corresponde diretamente à estrutura das suas três camadas. É a base regulatória internacional para justificar que validação não é única, é progressiva e multidimensional. Seu capítulo está, na prática, operacionalizando esse framework.

 

2. FDA – Good Machine Learning Practice (GMLP)

 

3. WHO – Ethics and Governance of AI for Health (2021)

  • WHO. Ethics and Governance of Artificial Intelligence for Health. 2021.
  • 🔗 https://www.who.int/publications/i/item/9789240029200
  • Este documento sustenta o eixo ético do seu capítulo. Ele mostra que a IA em saúde deve ser desenvolvida com base em transparência, responsabilidade, equidade e segurança do paciente. É essencial para justificar a sua ideia de que a ética não é uma etapa, mas um eixo transversal crescente ao longo do TRL. Dá base internacional para a integração entre validação e governança.

4. ISO 14971:2019 – Gestão de Risco

  • ISO. ISO 14971:2019 – Medical devices — Application of risk management to medical devices.
  • 🔗 https://www.iso.org/standard/72704.html
  • Essa norma sustenta profundamente a sua camada base, validação técnica. Ela estabelece que todo dispositivo médico deve ter identificação, análise, avaliação e controle de riscos ao longo de todo o ciclo de vida. É a base para a sua afirmação de que um sistema pode funcionar, mas ainda assim ser inseguro. Sem gestão de risco, não há base para qualquer validação superior.

5. Kelly et al., 2019 – BMC Medicine

  • Kelly CJ, Karthikesalingam A, Suleyman M, Corrado G, King D. Key challenges for delivering clinical impact with artificial intelligence.
    BMC Medicine. 2019.
  • 🔗 https://bmcmedicine.biomedcentral.com/articles/10.1186/s12916-019-1426-2
  • Este artigo conecta diretamente com a sua tese central. Ele demonstra que muitos sistemas de IA falham não por falta de performance técnica, mas por não conseguirem gerar impacto clínico real. Sustenta fortemente a sua camada topo e a crítica ao uso isolado do TRL. É uma referência científica robusta para a ideia de que desempenho não garante utilidade clínica.

 

Declaração de Uso de Inteligência Artificial Generativa (IAG). Declara-se que foi utilizada a ferramenta de Inteligência Artificial Generativa chatGPT, desenvolvida pela empresa OpenAI, como apoio na organização de ideias e na redação preliminar de trechos textuais deste trabalho e criação de imagens. O uso da ferramenta teve finalidade exclusivamente auxiliar na estruturação e revisão linguística do texto. Todas as decisões, interpretação, redação final e responsabilidade pelo conteúdo permanecem integralmente sob responsabilidade do autor.

***