A Internet Engineering Task Force (IETF) - organização internacional aberta que desenvolve e promove padrões técnicos para a internet, como os protocolos TCP/IP, HTTP e DNS - acaba de lançar a RFC 9745, que define uma forma padronizada de se informar a depreciação de recursos no contexto do HTTP, o que é especialmente relevante para APIs baseadas neste protocolo. Em resumo, a partir de agora, servidores podem informar seus clientes sobre o status de depreciação de determinados recursos utilizando o cabeçalho de resposta Deprecation, cujo valor é uma data, no passado ou futuro, indicando que o recurso já foi ou ainda será depreciado. Adicionalmente, é possível utilizar o cabeçalho link para apontar uma documentação e, também, o Sunset, trazendo a data na qual o recurso se tornará indisponível. Neste artigo iremos avaliar a viabilidade de se aplicar este padrão no mundo real. Utilizando as melhores práticas no desenvolvimento de APIs, partiremos de arquivos de definição que seguem a OpenAPI Specification e terminaremos no API gateway KrakenD. Impactos Como dito, este novo padrão é especialmente importante para as web APIs, ou seja, para as APIs que aderem ao protocolo HTTP, como as famosas REST. Neste contexto, a RFC oferece meios de se levar as políticas de depreciação — outrora restritas à documentação ou ao design time — ao tempo de execução. Portanto, a novidade tem o potencial de seriamente mitigar as quebras de integração, possibilitando aos desenvolvedores realizarem as adaptações necessárias com uma antecedência confortável. Aliás, vale lembrar que estamos entrando na era da A.I. (com seus agentes, servidores MCP e etc.), o que só faz aumentar o impacto deste novo padrão, já que eles podem aprender e se adaptar sozinhos diante da sinalização de depreciação. No contexto de governança, a RFC também torna possível aos fornecedores de gateways de API (como Kong, Tyk, KrakenD, Traefik, APISix e etc.) considerarem o novo padrão durante os processos automatizados de deploy de APIs, sobretudo quando pensamos em APIOps baseado em OpenAPI specification. Vejamos. A especificação OpenAPI prevê a indicação de depreciação de operações através do campo deprecated. Com esta nova RFC, é simplesmente natural pensarmos em linkar as coisas, ou seja, fazer com que a indicação de depreciação presente nos arquivos de definição encontre correspondência na configuração dos gateways, que, uma vez em execução, passem a injetar o novo cabeçalho de resposta nas operações apropriadas. Esta melhoria levaria a governança ao próximo nível de qualidade! Provando o conceito Utilizaremos o arquivo de definição aderentes à OpenAPI Specification (OAS) para descrever nossa API, construiremos um parser em Go utilizando a libopenapi, contaremos com o KrakenD como API gateway e um HttpBin como backend. Todos os detalhes do projeto podem ser encontrados neste repositório. Então, vou destacar apenas os pontos principais: O arquivo de definição (openapi.yaml) paths: (...) /users/{userId}: (...) delete: (...) deprecated: true Observe que a operação de deleção de usuário conta com o campo padrão da OAS deprecated com o valor true. Bem, é fácil perceber que estamos diante de uma incompatibilidade de impedância quando tentamos fazer esse booleano interagir com os novos cabeçalhos previstos na RFC 9745, já que estes são muito mais ricos em informação do que aquele. Por razões como esta, a OAS possui extensões, que, no nosso caso, serão utilizadas para descrever as propriedades esperadas pela RFC da seguinte forma: paths: (...) /users/{userId}: (...) delete: (...) deprecated: true x-deprecated-at: "2025-06-30T23:59:59Z" x-deprecated-sunset: "2026-01-01T00:00:00Z" x-deprecated-link: https://api.example.com/deprecation-policy O Parser A função do parser é ler e interpretar o arquivo de definição openapi.yaml, extrair as informações relevantes para o gateway, e criar o arquivo operations.json, que será embarcado na imagem do KrakenD e consumido durante a sua inicialização, numa abordagem denominada configuração flexível. Este é o resultado do operations.json: { "list": [ { "path": "/users", "method": "get", "backend": { "path": "/users", "host": "http://backend:8888" } }, { "path": "/users", "method": "post", "backend": { "path": "/users", "host": "http://backend:8888" } }, { "path": "/users/{userId}", "method": "get", "backend": { "path": "/users/{userId}", "host": "http://backend:8888" } }, { "path": "/users/{userId}", "method": "delete", "deprecated": { "at": "@1751327999", "link": "https://api.example.com/deprecation-policy", "sunset": "Thu, 01 Jan 2026 00:00:00 UTC" }, "backend": { "path": "/users/{userId}", "host": "http://backend:8888" } } ] } Observe que o parser projetou os elementos estendidos da OAS no arquivo de configuração do KrakenD, inclusive fazendo as devidas conversões de valores, da seguinte forma: OAS KrakenD x-deprecated-at: deprecated.at: x-deprecated-link: deprecated.link: x-deprecated-sunset: deprecated.sunset: O plugin Agora que a configuração do gateway foi devidamente gerada a partir do arquivo de definição, nosso plugin personalizado entra em cena. A sua função é identificar as operações de API depreciadas e inserir os cabeçalhos da RFC 9745 com os valores adequados. Mais detalhes podem ser encontrados no repositório do artigo. Mas, uma vez que o plugin foi embarcado no KrakenD, temos os seguintes resultados: GET /users/1 DELETE /users/1 Observe que apenas a segunda operação estava depreciada (vide operations.json) e o gateway adicionou corretamente os cabeçalhos na resposta. Conclusões O experimento mostrou a viabilidade do conceito, ou seja, que é possível levar as políticas de depreciação para além da definição e documentação, sendo facilmente comunicadas em tempo de execução. Desta forma, os sistemas podem adotar ações automatizadas para comunicar a obsolescência aos interessados e reduzir significativamente as chances de falhas nas integrações. Embora as extensões da OpenAPI Specification tenham tornado isso possível diante da insuficiência do booleano deprecated, imagino que a OpenAPI Initiative deve incluir uma melhoria nas próximas versões. Sobretudo quando penso que Eric Wilde, co-autor desta RFC, é bem atuante no mundo das APIs. Aos leitores que chegaram até aqui, meu muito obrigado. Espero que estas poucas palavras lhes tenham acrescentado algo e feito o seu tempo valer a pena. Referências RFC 9745: https://www.rfc-editor.org/rfc/rfc9745 OpenAPI Specification: https://spec.openapis.org/oas/latest.html Incompatibilidade de Impedância: https://devblogs.microsoft.com/oldnewthing/20180123-00/?p=97865 Repositório: https://github.com/MichelFortes/articles-RFC9745 HttpBin: https://hub.docker.com/r/michelfortes/httpbin KrakenD – flexible configuration: https://www.krakend.io/docs/configuration/flexible-config PB33F - libopenapi: https://pb33f.io/libopenapi/

Sabemos que com o surgimento de diversas tecnologias, há um grande aumento do número de termos que ouvimos falar, embeddings é um deles, mas o que são?Embeddings, que em inglês significa "incorporar", é um termo utilizado em IA e Processamento de Linguagem Natural (PLN). Refere-se ao processo de "incorporar" ou "embutir" informações complexas (como palavras, frases ou documentos) em um espaço vetorial. Isso significa que dados que seriam difíceis de processar diretamente são transformados em uma forma numérica (vetores), que os modelos de Machine Learning podem entender e usar para tarefas como classificação e análise semântica. Quando combinados com bancos de dados vetoriais, possibilitam que sistemas analisem grandes volumes de dados não estruturados. Isso permite a extração de informações relevantes e consultas complexas de forma rápida e eficaz. Essa técnica de transformação de dados é essencial na construção de soluções escaláveis, pois a representação vetorial facilita a busca e recuperação de informações além de comprimir suas informações e ainda assim manter a relação com o seu conteúdo original. Como funciona Sabemos que Embeddings são vetores para entendimento de máquina baseados em textos, fases, documentos. Mas como transformamos essas informações em vetores?Os vetores são formados a partir da utilização de modelos de IA treinados para identificar contextos, classificando-os com base na aproximação do contexto em números, que normalmente variam de -1 a 1. O valor 1 indica a maior proximidade, com milhares de parâmetros de comparação. Esses modelos são geralmente treinados com grandes volumes de texto, identificando padrões de concorrência entre palavras que aparecem frequentemente em contextos semelhantes, como "gato" e "animal". Durante o treinamento, o modelo aprende a mapear essas palavras para vetores numéricos em um espaço multidimensional, de forma que palavras com significados relacionados ou contextos similares fiquem posicionadas mais próximas entre si nesse espaço vetorial. O objetivo é fazer com que palavras ou frases com significados semelhantes fiquem mais próximas no "espaço" dos vetores. Por exemplo, "gato" e "cachorro" devem ser representados por vetores próximos, enquanto "gato" e "carro" estarão mais distantes. Exemplo de embedding | Imagem: https://arize.com/blog-course/embeddings-meaning-examples-and-how-to-compute/ De que forma é calculada a semelhança entre dois vetores, comparando, por exemplo, um texto com diversos vetores do modelo treinado?Matematicamente se utiliza normalmente a técnica de similaridade por cosseno para realizar a comparação entre dois vetores A similaridade do cosseno fornece um valor no intervalo [-1,1], tendo 1 como o valor de contexto mais próximo e -1 o mais distante [1] Equação de similaridade por cosseno | Imagem: Wikipedia Dois vetores com 98% de similaridade com base no cosseno do ângulo entre os vetores | Imagem: Richmond Alake Embeddings, na prática Análise de PDF com QA (Question Answering): Embeddings são usados em sistemas de análise de documentos, como PDFs, para realizar tarefas de Pergunta e Resposta (QA). Empresas que lidam com grandes volumes de documentos, como contratos ou relatórios, podem utilizar embeddings para localizar automaticamente trechos relevantes em um texto. Por exemplo, ao analisar um contrato em PDF, os embeddings permitem mapear semanticamente o conteúdo e identificar passagens relacionadas a perguntas como "Qual é o prazo de validade deste contrato?" ou "Quais são as obrigações de pagamento do cliente?". Em seguida, um modelo de IA generativa pode utilizar esses trechos para interpretar o contexto e gerar respostas em linguagem natural com maior precisão. Recomendação de Produtos (E-commerce): Plataformas como Amazon e Netflix utilizam embeddings para recomendar produtos ou filmes baseados nas preferências e comportamentos passados dos usuários. Por exemplo, ao recomendar filmes, embeddings são usados para capturar o estilo, gênero e características dos filmes que o usuário assistiu, sugerindo novos conteúdos com base na similaridade vetorial. Análise de Sentimentos (Atendimento ao Cliente): Empresas utilizam embeddings para analisar sentimentos em feedbacks ou mensagens de clientes. Por exemplo, ao analisar um conjunto de comentários em redes sociais ou e-mails de clientes, embeddings ajudam a identificar automaticamente se o sentimento é positivo, negativo ou neutro, permitindo uma resposta rápida e apropriada. Conclusão Embeddings têm se mostrado uma ferramenta poderosa e crescente em diversas indústrias, transformando a forma como interagimos com dados não estruturados. Sua capacidade de representar informações complexas de maneira numérica tem levado a melhorias em sistemas de análise de documentos, recomendações e até no atendimento ao cliente. Sendo uma tecnologia em constante evolução, é esperado que, com o tempo, ela seja cada vez mais integrada em soluções inteligentes e escaláveis. Além disso, com a tendência de redução dos custos computacionais e o avanço das infraestruturas de processamento e armazenamento, torna-se cada vez mais viável escalar essas soluções com eficiência e baixo custo. Referências https://builtin.com/machine-learning/cosine-similarity#:~:text=Cosine%20similarity%20is%20a%20measurement,within%20an%20inner%20product%20space https://arize.com/blog-course/embeddings-meaning-examples-and-how-to-compute

Empresas enfrentam desafios diários na gestão de infraestrutura Kubernetes, especialmente para manter eficiência e reduzir custos. Aqui na Softplan, descobrimos uma solução que transforma a maneira de gerenciar nossos clusters EKS na AWS: o Karpenter. Desafios na gestão de instâncias Antes de falar de Karpenter é preciso dar alguns passos atrás e explicar um pouco do que se trata um auto escalonamento de nodes. Suponha que temos nosso cluster com algumas máquinas (instâncias) disponíveis executando nossos workloads. O que acontece se por acaso houver um pico de uso em nossas aplicações e seja necessário subir mais instâncias (réplicas) de nossos pods? Sem um autoscaling precisaríamos provisionar um node, orientá-lo a juntar-se ao nosso cluster para aí sim nossos pods estarem aptos a serem iniciados nessa nova instância. Lembrando que o provisionamento de uma instância não é instantâneo, há todo um bootstrapping da máquina, configurações de rede e muitas outras coisas antes dela ficar totalmente disponível. Certo, falamos sobre pico de usuários em nossas aplicações, mas e quando houver ociosidade? Queremos mesmo deixar esses nodes em pé com poder computacional subutilizado? Para resolver essa e outras questões, entra em cena o conceito de auto scalers. Auto Scalers As implementações de auto scalers são responsáveis basicamente pelo provisionamento e consolidação de nodes. Aqui estamos falando de escalonamento horizontal, ou seja, adicionando mais máquinas em nosso cluster. Há diversas implementações de node autoscaling, mas neste artigo o foco será na implementação da AWS e por que decidimos migrar para uma outra solução. Abaixo uma figura exemplificando o funcionamento do node autoscaling: Figura 01: autoscaling AWS - Auto Scaling Groups Ao definir um grupo de escalonamento na AWS precisamos definir diversas propriedades, como o número mínimo/máximo de instâncias de nodes permitidas para este grupo, recursos utilizados, tipo de disco, configurações de rede (subnets, etc) e muitos outros detalhes. Por exemplo, para um determinado tipo de aplicação que utilize mais CPU vamos configurar um grupo que contenha tipos de instância com mais CPU do que memória. No fim possivelmente teremos alguns grupos distintos para certos tipos de aplicações. Juntando as peças – Cluster Auto Scaler Para que meu cluster consiga “conversar” com meu cloud provider (neste exemplo AWS), precisamos de um componente chamado Cluster Auto Scaler, ou CAS.Este componente foi criado pela própria comunidade que mantém o Kubernetes, e está disponível aqui. Uma configuração padrão do CAS pode ser vista abaixo, utilizando o helm para instalação: nameOverride: cluster-autoscaler awsRegion: us-east-1 autoDiscovery: clusterName: meu-cluster image: repository: registry.k8s.io/autoscaling/cluster-autoscaler tag: v1.30.1 tolerations: - key: infra operator: Exists effect: NoSchedule nodeSelector: environment: "infra" rbac: create: true serviceAccount: name: cluster-autoscaler annotations: eks.amazonaws.com/role-arn: "role-aws" extraArgs: v: 1 stderrthreshold: info Com isso configurado e instalado e nossos autoscaling groups criados acabamos de habilitar o gerenciamento automático de nossos nodes! Por que decidimos migrar para o Karpenter Nosso caso de uso aqui na Projuris é o seguinte: temos um cluster de desenvolvimento e outro de produção. Depois da migração para o Gitlab SaaS tínhamos um desafio de como provisionar os runners para a execução de nossas pipelines. Ficou decidido que usaríamos o cluster de desenvolvimento para provisionamento desses runners. Na “primeira versão” optamos pelo cluster auto scaler por ser uma configuração mais simples e que já atendia nosso setup em produção. Mas aí começamos a enfrentar alguns problemas com esta escolha: Tempo de provisionamento: ao iniciar uma pipeline o tempo de provisionamento da máquina era um pouco lento. O grande ponto é que o cluster auto scaler paga um “pedágio” no cloud provider para provisionamento de um novo node. Dificuldade na configuração de grupos: como temos alguns “perfis” de pipeline essa gestão ficou um pouco complicada, porque para cada novo perfil um novo node group precisa ser criado. Custo: para mitigar o problema de lentidão no startup de um novo node tínhamos um perfil de máquina “online” que ficava o tempo todo de pé, mesmo sem executar nenhuma pipeline. O que é o Karpenter? É uma solução de cluster autoscaling criada pela AWS, que promete o provisionamento e consolidação de nodes sempre com o menor custo possível. Ele é inteligente o suficiente para saber que por exemplo, ao comprar uma máquina na AWS do tipo on-demand, dependendo da situação, é mais em conta do que se fosse uma máquina spot. E essa é apenas uma das características dessa ferramenta. O Karpenter também trabalha com a ideia de “grupos” de máquinas (que no mundo do Karpenter chamamos de NodePools), só que a diferença é que fazemos isso através de CRDs (custom resource definitions) do próprio Karpenter, ou seja, temos manifestos dentro de nosso cluster com todas essas configurações, eliminando a necessidade de qualquer node group criado na AWS. Exemplo de um NodePool no Karpenter: apiVersion: karpenter.sh/v1 kind: NodePool metadata: name: karpenter-gitlab-runner-small-online spec: template: metadata: labels: workload: gitlab-runners environment: karpenter-nodes-gitlab-runner-build-small-online spec: requirements: - key: "karpenter.sh/capacity-type" operator: In values: ["spot", “on-demand”] - key: "node.kubernetes.io/instance-type" operator: In values: ["m5d.large", "m5n.large", "m6id.large", "m6in.large"] nodeClassRef: group: karpenter.k8s.aws kind: EC2NodeClass name: my-node-class taints: - key: "gitlab-runner-karpenter" value: "true" effect: NoSchedule expireAfter: Never disruption: consolidationPolicy: WhenEmpty consolidateAfter: 5m budgets: - nodes: "20%" limits: cpu: "500" memory: 500Gi Além do NodePool precisamos criar um NodeClass para definir detalhes específicos de instâncias AWS: apiVersion: karpenter.k8s.aws/v1 kind: EC2NodeClass metadata: name: my-node-class spec: amiFamily: AL2 role: "aws-role" tags: Name: nodes-k8s-nodes-gitlab-runner-small-online subnetSelectorTerms: - tags: karpenter.sh/subnet: "my-subnet" securityGroupSelectorTerms: - id: "sg-123" - id: "sg-456" - id: "sg-789" amiSelectorTerms: - id: "imagem ami" kubelet: clusterDNS: ["111.222.333.44"] blockDeviceMappings: - deviceName: /dev/xvda ebs: volumeSize: 40Gi volumeType: gp3 encrypted: true OBS: perceba que o nome “my-node-class” precisa bater com o node class configurado no node pool. Como o Karpenter nos ajudou a superar os desafios apresentados? Tempo de provisionamento: como o Karpenter conversa diretamente com as APIs do cloud provider não é necessário pagar o pedágio do cluster auto scaler. Tínhamos muitos problemas de timeout no provisionamento de novos nodes, após a troca pelo Karpenter esse problema simplesmente desapareceu justamente porque o provisionamento é mais eficiente. Dificuldade na configuração de grupos: com a solução de NodePools e NodeClass do Karpenter essa configuração ficou trivial, e o mais importante, versionada em nosso controle de versões no Gitlab. Ou seja, precisa incluir um perfil de máquina novo no NodePool? Sem problemas, basta um commit e o Karpenter já irá considerar isso nos novos provisionamentos. Custo: Conseguimos utilizar a utilização de máquinas, pois agora runners com características semelhantes são alocados em nodes que suportem os requisitos de memória e CPU exigidos. Ou seja, estamos realmente usando todo o poder computacional que aquele node proporciona. Isso vale também para a consolidação de nodes. Com o cluster auto scaler haviam scripts complexos para fazer o drain dos nodes antes da consolidação. Com o Karpenter isso é configurado no NodePool de maneira muito simplificada. Um ótimo argumento para a gestão que justifique o investimento nesse tipo de mudança é custo. Abaixo temos um comparativo do custo utilizando o Cluster AutoScaler e o Karpenter em Janeiro/25, onde conseguimos uma economia de 16% no total: Figura 02: Período de 01/01 à 15/01 com ClusterAutoScaler Figura 03: Período de 16/01 à 31/01 com o Karpenter Considerações finais A migração para o Karpenter foi uma escolha acertada. Conseguimos simplificar a gestão de nossos nodes com diferentes perfis de forma bastante simplificada. Ainda há espaço para algumas melhorias, como por exemplo a utilização de um único NodePool para simplificar ainda mais, e deixar que os runners configurem labels específicas para o perfil de máquina que deve ser provisionado para o runner (mais em https://kubernetes.io/docs/reference/labels-annotations-taints/). Referências Karpenter (doc oficial): https://karpenter.sh/ Node Auto Scaling (doc oficial k8s): https://kubernetes.io/docs/concepts/cluster-administration/node-autoscaling/

A startup, que faz a gestão de processos digitais em prefeituras e já pertencia majoritariamente ao Grupo desde 2019, apresentou crescimento expressivo de 75% ao longo de seis anos  Florianópolis, abril de 2025 – O Grupo Softplan, uma das maiores empresas de SaaS e de transformação digital do Brasil, acaba de oficializar a aquisição da totalidade da 1Doc, especializada na digitalização de processos, comunicação institucional e atendimento ao cidadão em prefeituras e órgãos públicos. Em uma jornada que teve início em 2017 com um aporte estratégico e, posteriormente em 2019, com a compra majoritária da empresa, a companhia finaliza a compra do restante junto a Jéferson de Castilhos, um dos fundadores, e passa a deter 100% da startup. No ano passado, a participação de Jaison Niehues, outro sócio fundador, já havia sido adquirida.   Compondo a vertical de Setor Público do grupo desde 2019, a 1Doc apresentou uma Taxa de Crescimento Anual Composta (CAGR) de 75% entre 2019 e 2025. “A jornada com a 1Doc representa exatamente como acreditamos que a relação com o ecossistema de inovação e startups deva acontecer: com visão a longo prazo, colaboração e impacto real. A startup cresceu dentro do ecossistema Softplan, evoluiu com autonomia e agora se consolida como uma peça-chave da nossa estratégia para transformar o setor público”, afirma Eduardo Smith, CEO do Grupo Softplan.   Fundada em 2014, a 1Doc nasceu com o propósito de digitalizar processos e aproximar cidadãos e governos por meio de uma plataforma 100% em nuvem. Hoje, atende em média 1000 entidades em todo o país e conta com um time de 141 colaboradores, reforçando seu alcance e relevância no setor público, sendo responsável por impactar diretamente a vida de mais de 22 milhões de brasileiros.  "Temos grande apreço pela cultura da 1Doc e muito orgulho da trajetória de crescimento que construímos ao longo dos anos, sempre guiados por um propósito claro. Hoje, temos plena certeza do impacto positivo que nossos serviços geram, facilitando a rotina de nossos clientes — que reconhecem tanto o valor das nossas soluções quanto a relevância do trabalho que entregamos”, celebra Alice Luz, CEO da 1Doc.  A compra vai permitir ampliar a integração que já existe entre os produtos, possibilitando o desenvolvimento de funcionalidades em parceria entre Softplan Setor Público e 1Doc, trazendo expertises de funcionalidades com o uso de inteligência artificial e machine learning voltadas à automatização de processos, validação e classificação documental e atendimento digital em larga escala.  “A 1Doc trouxe para o nosso portfólio uma solução altamente escalável e de fácil implantação, capaz de atender desde pequenos municípios até grandes centros urbanos. Hoje, essa solução é parte central da nossa entrega para cidades e entidades mais eficientes, conectados e centrados no cidadão”, explica Márcio Santana, Diretor Executivo da Softplan Setor Público.  Estratégia de aquisições   Com a 1Doc totalmente integrada ao portfólio, a empresa ampliará sua capacidade de oferecer uma jornada digital completa — da tramitação documental ao atendimento ao cidadão — com soluções SaaS, em nuvem e de fácil escalabilidade.  “A trajetória com a 1Doc é um exemplo claro da nossa estratégia de aquisições: identificar empresas com alto potencial de crescimento e forte sinergia com nosso negócio. Desde o primeiro investimento, nosso objetivo foi impulsionar a solução, unindo capacidades e ampliando o valor entregue ao cliente final. A aquisição total consolida esse movimento e reforça nosso compromisso em construir jornadas mais eficientes e conectadas para os nossos clientes”, afirma Alex Anton, Diretor de M&A e Estratégia do Grupo Softplan.   A compra da startup fortalece também a atuação do grupo junto ao movimento de cidades inteligentes, promovendo inovação com foco em transparência, participação cidadã, redução de custos e maior eficiência da máquina pública. 

Empresa especialista em robôs de automação para o mercado jurídico é a 13ª aquisição da companhia; estratégia da Softplan Inteligência Legal é complementar o portfólio de soluções Projuris para escritórios de advocacia e departamentos jurídicos Florianópolis, abril de 2025 – O Grupo Softplan, um dos maiores ecossistemas de tecnologia e SaaS do país, segue sua estratégia de crescimento e anuncia a aquisição da Oystr, legaltech especializada em automação de fluxos jurídicos e gestão de certificados digitais. A empresa passa a integrar o portfólio da Softplan Inteligência Legal, vertical dedicada a soluções para o setor jurídico e escritórios de advocacia, que tem a Projuris como principal solução. Essa é a 13ª aquisição da companhia em seus 34 anos de história. Desde 2020, o Grupo Softplan tem intensificado essa estratégia, totalizando 12 aquisições nos últimos cinco anos. Com essa nova movimentação, a Softplan Inteligência Legal amplia seu portfólio com soluções que automatizam tarefas jurídicas, como captura de publicações, peticionamento eletrônico, gestão de certificados digitais. A solução se integra a sistemas externos, otimizando fluxos de trabalho e aumentando a eficiência dos profissionais do setor. “Monitoramos o potencial da Oystr no mercado e identificamos a oportunidade de fortalecer ainda mais nossa vertical. Essa aquisição amplia a integração de soluções de automação e potencializa o uso da Inteligência Artificial em nossos produtos”, destaca Eduardo Smith, CEO do Grupo Softplan. Já para Rafael Caillet, CEO da Oystr, a aquisição representa um marco importante nos mais de 10 anos de história da startup, que também tem Leandro Cruz e Jonas Pacheco como sócios-fundadores. “Integrar nossa solução ao maior ecossistema jurídico do país é um passo fundamental para impulsionar a automação no setor e ampliar a eficiência dos profissionais”, aponta o executivo. Recentemente, a empresa lançou o Presto, solução inovadora para gestão de credenciais e certificados digitais. Com a inclusão da Oystr em seu portfólio, a Softplan Inteligência Legal projeta um crescimento de 38% para o ano de 2025, em relação a 2024. Sidney Falcão, diretor executivo da unidade de negócio, ressalta que a implementação de RPA (Automatização de Processos Robóticos) é um diferencial estratégico para maximizar a produtividade e eficiência dos clientes. “Nosso compromisso é oferecer uma experiência completa, que vai desde a otimização de tarefas repetitivas até a gestão integrada de documentos e processos jurídicos. Identificamos sinergias que não apenas agilizam as operações, mas também agregam valor direto ao mercado”, conclui. O crescimento inorgânico do Grupo Softplan considera pilares como sinergia de produtos e cultura organizacional. “Nosso processo de M&A avalia cuidadosamente a complementariedade das soluções e a afinidade cultural entre as empresas. Isso garante que entreguemos um ecossistema mais robusto aos clientes e potencializemos os talentos das duas operações”, explica Smith. Potencial de tecnologia Os robôs utilizados pela Oystr são multi sistemas, o que pode vir a aumentar o fluxo de tarefas. “Ao todo, temos mais de 480 robôs ativos, mas se considerarmos que o mesmo robô que realiza uma tarefa na Bahia também atua em Roraima, no Paraná ou em qualquer outro estado, este indicador aumenta consideravelmente, impulsionando o fluxo de sistemas em todo o país”, diz Rafael Caillet. A empresa possui alta capacidade de processamento de dados, o que por sua vez potencializa a automação de diversos escritórios de advocacia e departamentos jurídicos. Nos últimos seis anos, os robôs da Oystr realizaram mais de 250 milhões de tarefas. Foram mais de 600 empresas impactadas que, por meio de tecnologia de ponta, tornaram seus negócios mais eficientes e sustentáveis. Fundada em 2014 para automatizar tarefas jurídicas repetitivas e custosas, os mais de 1.000 robôs já desenvolvidos pela Oystr realizam a coleta de intimações, protocolos em massa, alimentação de sistemas internos, entre outras funções. Seus mais de 300 clientes incluem Nelson Wilians Advogados, Mascarenhas Barbosa Advogados, Góes & Nicoladelli, Pereira Gionedis Advogados, Pellon & Associados, Unimed Curitiba. Sócios-fundadores da Oystr: Jonas Pacheco, CTO (esquerda); Rafael Caillet, CEO (centro); Leandro Cruz, Head de Big Data e Machine Learning (direita)

Referência em transformação digital para o setor público brasileiro e colombiano, a empresa expande a atuação na América Latina implementando soluções tecnológicas em processos judiciais em todo o território peruano.   Florianópolis, março de 2025 – A Softplan Setor Público, pioneira em automação de processos para instituições públicas e uma das verticais de atuação do Grupo Softplan, venceu uma licitação internacional e passa a trabalhar junto com o Poder Judicial do Peru. O contrato está entre os maiores já firmados e endossa o plano estratégico de não apenas exportar alta tecnologia, mas também apresentar a outros países o modelo de justiça digital brasileiro. O projeto denominado EJE NO PENAL evidencia a robustez da solução tecnológica, que é referência no Brasil, e que também foi adotada pela Jurisdição Especial para a Paz (JEP), na Colômbia - justiça transicional criada com o propósito de reparação com o acordo de paz entre o Governo Nacional e as FARC-EP.  O contrato com o Poder Judicial do Peru consiste na implementação de uma plataforma tecnológica para gestão de processos não criminais em todo o território peruano, reforçando a Softplan Setor Público como trusted advisor em transformação digital em governos e Justiça. Com isso, o governo peruano terá o apoio tecnológico para suprir a necessidade de aperfeiçoar os processos judiciais, trazendo tecnologias de ponta, por meio do produto SAJ Tribunais, que assegura uma significativa redução no tempo de tramitação, elevando a eficiência, transparência e acesso aos serviços judiciais à população. A solução tem hoje mais de 27 milhões de processos judiciais em tramitação e outros 100 milhões já foram finalizados.  “Este é um projeto de relevância por abranger o judiciário de todo um país. Será um momento de transformação digital para os nossos vizinhos e poder contribuir com a expertise da Softplan Setor Público nesse desafio nos traz uma responsabilidade e orgulho imenso das nossas tecnologia e experiência. Em termos de estratégia, a internacionalização faz parte de um dos nossos principais objetivos de crescimento e contar com o Poder Judicial do Peru no portfólio endossa ainda mais a nossa estratégia”, destaca Márcio Santana, Diretor Executivo da Softplan Setor Público.     “Este acordo representa um marco histórico para o Poder Judiciário e para o país, um ponto de viragem na modernização do sistema judicial, permitindo a implementação de soluções tecnológicas inovadoras que irão transformar a administração da justiça e a gestão dos processos”, disse a presidente do Poder Judicial do Peru, a juíza suprema Janet Ofelia Lourdes Tello Gilardi. (...) A revolução tecnológica na administração da justiça ocorrerá então, maior eficiência, redução do tempo processual, otimização da carga de trabalho, a digitalização minimizará atrasos desnecessários, transparência nos processos judiciais, garantia de acesso à informação promovendo uma maior justiça acessível e fiável”, complementou.   Com a assinatura formalizada, os servidores do Poder Judicial Peruano terão à disposição uma solução de processos digitais com benefícios que permitem manter a integridade, segurança e consistência, além de apoiar a tomada de decisões com base em informações de processos.   “Com o marco da assinatura do contrato temos pela frente um projeto de modernização que envolve 34 Cortes Superiores de Justiça em todo o Peru Serão mais de 18 mil usuários e aproximadamente 1.700 órgãos envolvidos na implantação deste projeto. Iniciaremos por uma etapa de parametrização da solução à realidade local e depois seguiremos com treinamentos e acompanhamento assistido dos usuários no processo de apropriação da solução. Desafio este de magnitude e impacto nacional, reforça Márcio quanto à execução do projeto.   Há mais de 30 anos no mercado, a Softplan Setor Público oferece um serviço pioneiro na implementação de processos digitais na justiça brasileira, promovendo soluções que garantem agilidade, transparência e eficiência em todos os processos. Somente em 2024, 201 milhões de brasileiros foram impactados pelas soluções promovidas pela companhia, o que equivale a 91% da população brasileira. Com relação à eficiência, os tribunais que utilizam o SAJ tiveram redução de até 90% no tempo entre a distribuição do processo e o primeiro ato do magistrado; 6,2 mil horas economizadas na distribuição automática de processos e 19,5 milhões de horas otimizadas com a incorporação automática de documentos – os números se referem ao período de 2015-2020.    Com relação à economia com a digitalização de processos e redução de impacto ambiental, desde 2009 o sistema evitou 22,6 bilhões de impressões de páginas, possibilitando a não emissão de 596 mil toneladas de CO2, o que equivale às emissões combinadas de uma frota de 864,5 mil toneladas de CO2. A eliminação do papel proporcionou aos Tribunais SAJ uma economia financeira da ordem de 261,3 milhões de reais apenas em 2024. No acumulado, desde 2009, a economia estimada é de 2,26 bilhões de reais.