VENËEN

Article · IA & comptabilité

L'IA qui décide, pas celle qui bavarde : le smart IF entre en comptabilité

par José Vazquez

6 octobre 2026

Le smart IF : une décision typée, une confiance calibrée, et le code qui tranche. Au-dessus du seuil (0,80), action automatique ; en dessous, escalade vers un humain.

Les outils d'IA disponibles aujourd'hui sont d'une puissance phénoménale. Ils résument une boîte mail en quelques secondes, proposent des réponses toutes prêtes, rédigent des contenus, produisent des analyses. L'impression de magie est réelle, et elle est méritée.

Et pourtant, une question gêne, et il faut oser la poser : où est le gain de productivité, le vrai, celui qui justifierait le coût ? Parce que le coût n'est pas seulement celui des abonnements. C'est le changement d'organisation qu'il faut conduire, ce sont les tokens dont la facture grimpe avec l'usage, c'est une offre qui se réinvente tous les trois mois, au point qu'on n'est jamais sûr d'avoir misé sur le bon outil. Résumer des emails, proposer des brouillons, rédiger plus vite : oui, c'est utile. Mais regardons les choses en face, ces usages restent périphériques. Ils allègent des tâches. Ils ne transforment pas le métier.

Je le dis d'expérience, pas en théoricien. Chez Veneen, nous proposons à des cabinets Horalio, une solution ultra-simplifiée de gestion du temps. Et oui, c'est l'usage combiné de plusieurs LLM qui nous a permis de la produire, simplement, efficacement, à coût maîtrisé. L'IA a été, là, une aubaine réelle.

Mais posons la vraie question. En dehors des développeurs, qui peut aujourd'hui créer, avec un LLM, une application assez architecturée pour être pérenne et sécurisée ? Personne, ou presque. Pour l'informaticien, le LLM est une chance inouïe : il démultiplie un savoir-faire qu'il possède déjà. Pour les autres, il produit des maquettes séduisantes qui s'effondrent au premier vrai cas limite. Et c'est là le point aveugle de la hype. Mis à part les informaticiens, quels professionnels peuvent honnêtement dire, la main sur le cœur : j'ai un surcroît de valeur, grâce à l'IA, qui est tout simplement phénoménal ? Très peu. C'est tout le problème, et c'est précisément ce que le smart IF vient changer pour la comptabilité.

Pour une société d'expertise comptable, le calcul est encore plus serré. Un cabinet a besoin de sécurité, de stabilité, de permanence. Il vit de la fiabilité, pas de la nouveauté. Face à une hype marketing qui change de promesse chaque trimestre, beaucoup de cabinets sont tétanisés. Et ils ont raison de l'être. On ne refond pas une organisation réglementée au rythme des annonces.

Je crois que cette prudence n'est pas un retard. C'est une lucidité. Le problème n'est pas que l'IA manque de puissance, elle en déborde. Le problème est qu'on lui demande la mauvaise chose.

Car nous confondons deux usages très différents sous le même mot. D'un côté, écrire : résumer, reformuler, rédiger. De l'autre, décider : choisir un compte, trancher une ventilation, dire si deux lignes se lettrent. Les grands modèles de langage sont brillants pour le premier. Ils ne sont pas faits pour le second. Et c'est en les confondant que l'on a cru, à tort, qu'ils allaient automatiser la comptabilité. Ils ne le feront pas, pas tels quels. Une autre voie vient d'arriver à maturité, et c'est elle qui compte.

1. Le problème n'est pas que les LLM se trompent. C'est qu'ils se trompent avec aplomb.

Un mot sur ce qu'est un LLM, sans jargon. LLM veut dire « large language model », grand modèle de langage. C'est une IA entraînée à produire du texte en prédisant, mot après mot, la suite la plus plausible. C'est une machine à écrire ce qui sonne juste. Pas une machine à trancher ce qui est juste. La nuance paraît mince. Elle est décisive.

Un LLM est en effet entraîné à produire un texte qu'un humain jugera convaincant. C'est exactement son objectif, et il est redoutablement bon à cela. Le revers est connu : il hallucine. Il invente une référence, une règle, un numéro de compte, avec la même assurance que lorsqu'il a raison. Le ton ne trahit jamais l'erreur.

Pour un assistant de rédaction, c'est un défaut gérable. Pour une décision comptable, c'est disqualifiant. La comptabilité ne demande pas une prose plausible, elle demande une décision juste, et surtout une décision dont on connaît le degré de certitude. Un LLM ne vous donne ni l'un ni l'autre de façon fiable. Il vous donne une phrase.

Diogo Almeida, qui a co-inventé l'apprentissage par renforcement sur préférences humaines (la RLHF qui a donné ChatGPT), le formule aujourd'hui à l'envers chez TypeSafe AI : optimiser un modèle pour plaire à un lecteur récompense la flagornerie et les hallucinations qui sonnent juste. Plaire à un humain et être digne de confiance pour un logiciel sont deux objectifs d'entraînement différents. Nous avons passé trois ans à entraîner des modèles pour le premier, puis nous nous sommes étonnés qu'ils échouent au second.

2. La fausse parade : faire valider par un humain

Face à ce problème, l'industrie a trouvé une réponse réflexe : mettre un humain dans la boucle. Le LLM propose, l'humain valide. Rassurant sur le papier. Épuisant dans les faits.

Appelons cela par son nom, la fatigue de validation. Demandez à un collaborateur de contrôler, toute la journée, les sorties d'une machine qui a souvent raison mais parfois tort, sans prévenir, et il finit par baisser la garde. Pas par paresse. Par usure. Les premières heures, il vérifie vraiment. Puis le volume l'emporte. Il va plus vite, il valide par lots, il finit par valider des validations, à cocher sans plus vraiment juger.

Les effets de bord sont connus, et lourds :

la vigilance s'émousse là où elle devait nous protéger : les erreurs rares passent justement parce qu'elles sont rares, et qu'on ne les attend plus ;
la responsabilité glisse sur l'humain sans lui en donner les moyens : il signe pour une machine qu'il ne peut pas vraiment contrôler ;
le travail perd son sens : superviser sans décider, cocher sans arbitrer, ce n'est plus un métier, c'est un tampon ;
la charge mentale monte pendant que la valeur perçue baisse. On épuise les meilleurs profils sur la tâche la moins gratifiante.

Le vrai sujet n'est donc pas « comment faire relire un LLM par un humain ». C'est « comment obtenir une décision dont la fiabilité est portée par l'architecture, et non posée sur les épaules d'un humain qui s'épuise ».

3. Entrée en scène : Jev, et la catégorie des modèles « System One »

C'est là que l'arrivée de Jev, le modèle de TypeSafe AI, change la donne. Jev n'est pas un LLM amélioré. C'est une autre espèce, que TypeSafe appelle un modèle « System One », en référence à la pensée rapide et intuitive décrite par Daniel Kahneman.

Un mot sur cette référence. Dans « Système 1 / Système 2 », Daniel Kahneman distingue deux façons de penser. Le Système 2 est lent, délibéré, analytique : c'est lui qu'on sollicite pour une démonstration, une analyse approfondie, un raisonnement long. C'est le terrain des LLM et des modèles de raisonnement. Le Système 1 est rapide, intuitif, quasi instantané : c'est lui qui tranche en une fraction de seconde, par des décisions courtes mais à fort impact immédiat. La comptabilité quotidienne vit surtout dans le Système 1 : des milliers de petites décisions sûres, rapides, répétées. Jev joue précisément sur ce terrain-là.

La différence tient en une phrase. Comme un LLM, Jev comprend le langage naturel. Contrairement à un LLM, il ne rédige pas de réponse : il renvoie une décision typée et une probabilité calibrée. Vous ne lui demandez pas « que penses-tu de cette facture ? », vous lui posez une question dont vous avez défini à l'avance l'espace des réponses possibles :

un choix (quel compte, quel journal, quelle catégorie) ;
un score sur une échelle (niveau de risque, degré de cohérence) ;
un booléen (ces deux lignes se lettrent-elles, oui ou non), assorti d'une probabilité.

Et surtout, cette probabilité est calibrée. C'est le cœur du sujet. Un modèle calibré, c'est un modèle dont les probabilités veulent dire quelque chose : sur l'ensemble des cas auxquels il attribue 0,8, environ 80 % se révèlent justes ; sur ceux auxquels il attribue 0,95, environ 95 %. La probabilité cesse d'être un habillage cosmétique pour devenir une information exploitable par du code.

Pour comprendre d'où vient cette différence, il faut regarder trois façons d'entraîner une IA, qui donnent trois résultats :

RLHF (reinforcement learning from human feedback, apprentissage par renforcement à partir de retours humains), l'entraînement à plaire à un humain. On récompense le modèle quand sa réponse plaît. Il devient agréable, conversationnel. C'est ce qui a donné les chatbots, et c'est aussi ce qui récompense, sans le vouloir, la réponse qui a l'air juste.
RLVR (reinforcement learning with verifiable rewards, apprentissage par renforcement à récompenses vérifiables), l'entraînement sur des réponses vérifiables. On récompense le modèle quand sa réponse est démontrablement correcte, par exemple en mathématiques. Cela a donné les modèles de raisonnement, puissants mais lents et coûteux.
RLCD (reinforcement learning for calibrated decisions, apprentissage par renforcement pour des décisions calibrées), l'entraînement à des décisions calibrées. C'est la voie de Jev. On ne récompense pas une belle phrase, on récompense une décision juste assortie d'une probabilité honnête. Autrement dit, un modèle qui sait non seulement répondre, mais aussi dire à quel point il est sûr.

Leur formule résume l'intention : « construire de la prod, pas un dieu ». Non pas un modèle qui fait tout et qu'il faut surveiller, mais une brique étroite, rapide, que le logiciel peut inspecter et sur laquelle il peut agir.

4. Le smart IF : rendre la décision au code

C'est de cette calibration que naît ce que j'appelle le smart IF, l'IF intelligente. Et c'est, à mon sens, le vrai saut conceptuel.

Pendant soixante ans, le logiciel de gestion a reposé sur des règles déterministes, écrites en dur. Si le libellé contient « EDF », alors compte 606. Fiable, mais bête. Incapable d'absorber la variété infinie du réel comptable sans se transformer en forêt de règles ingérable.

Le LLM promettait de remplacer ces règles par de la compréhension. Mais il remplaçait aussi la certitude de la règle par le flou d'une phrase. On gagnait la souplesse, on perdait le contrôle.

Le smart IF réconcilie les deux. La décision sémantique, celle qui demande de comprendre le réel, est confiée à un modèle calibré. Le contrôle, lui, reste au code. Concrètement : le modèle rend une décision et une confiance, et le logiciel décide quoi en faire, de façon déterministe. Si la confiance dépasse un seuil, on agit automatiquement. Si elle est en deçà, on escalade vers un humain. La règle ne disparaît pas, elle devient intelligente : elle ne porte plus sur un mot-clé, elle porte sur un degré de certitude mesuré.

La fatigue de validation s'effondre d'elle-même. L'humain ne valide plus tout, il ne voit plus que les cas réellement incertains, ceux que l'architecture a identifiés comme tels. Sur un flux comptable, la part des cas à haute confiance est écrasante. Le jugement humain est enfin réalloué là où il a de la valeur, et retiré de là où il s'épuisait.

Jev reste probabiliste, je ne le nie pas. Mais sa fiabilité ne repose pas sur l'espoir qu'il ait raison. Elle repose sur son architecture et sur son pré-calibrage. Calibré sur un socle comptable (un plan de comptes, un référentiel PCG, un historique d'écritures, un FEC), un modèle de ce type ne devine pas dans le vide : il décide à l'intérieur d'un cadre connu, et il sait dire quand il n'est pas sûr. C'est une avancée réelle, pas une promesse marketing de plus. Et c'est exactement le genre de socle, stable et vérifiable, qu'un cabinet peut adopter sans se renier.

5. Les cas d'usage comptables, enfin

Ce qui, hier, trébuchait sur l'hallucination devient praticable :

la génération d'écriture, proposée avec un niveau de confiance, passée automatiquement au-dessus du seuil, soumise en dessous ;
le lettrage, posé comme un booléen calibré plutôt que comme une règle rigide ou un pari ;
la TVA, dont le taux et la ventilation deviennent une décision typée et traçable, pas une phrase à relire ;
le contrôle de cohérence, qui note en continu l'écart à la norme et remonte ce qui sort du cadre ;
la décision de ventilation analytique, longtemps réputée irréductible à la règle, enfin abordable comme un choix calibré.

Tout cela est utile. Mais ce n'est pas là, selon moi, que se joue l'essentiel.

6. Le vrai verrou : la normalisation des données

Il existe une difficulté que toute la profession connaît et dont personne ne parle, parce qu'elle est ingrate : les données comptables ne sont pas normalisées. Chaque entreprise a son plan de comptes, ses libellés maison, ses habitudes, ses héritages. Un même achat est logé dans dix comptes différents selon les dossiers. Les libellés sont une bouillie d'abréviations. D'un client à l'autre, la donnée dit la même chose dans une langue différente.

C'est le verrou qui a fait échouer, discrètement, à peu près toutes les promesses d'exploitation de la donnée comptable. On ne peut pas comparer, agréger, modéliser, conseiller sur des données qui ne parlent pas la même langue. Le benchmark sectoriel, le pilotage, le conseil de gestion fondé sur la donnée : tout cela bute sur la normalisation avant même de commencer.

On voit d'ailleurs fleurir la réponse à la mode, le datalake. Certains éditeurs proposent de déverser toutes les données comptables dans un grand lac de données, puis d'y brancher des panels, des tableaux de bord, des comparaisons, présentés comme l'optimum de l'exploitation de la donnée. L'idée est séduisante, mais elle met la charrue avant les bœufs. Un datalake n'enlève pas la saleté, il la stocke en plus grand. Si les données qui y entrent ne sont pas normalisées, le panel agrège des pommes et des poires derrière une belle interface. On empile de la donnée là où il fallait d'abord la faire parler la même langue. Le lac ne vaut que ce que vaut la normalisation en amont. Et c'est exactement la couche qui manque.

C'est précisément ce qu'un modèle de type System One sait faire, et c'est là que je situe l'avancée majeure. Normaliser, c'est fondamentalement classer : rattacher un libellé crasseux au bon poste normalisé, mapper un plan de comptes idiosyncrasique sur un référentiel commun, rapprocher des écritures hétérogènes d'une catégorie stable. Ce sont exactement des décisions typées et calibrées. Pas de la rédaction. De la classification, à grande échelle, pour un coût dérisoire, avec un degré de confiance sur chaque rattachement.

Normaliser la donnée comptable de façon fiable, c'est débloquer tout ce qui vient après. Une fois que les données de milliers de dossiers parlent la même langue, le cabinet cesse d'être un centre de production d'écritures pour devenir un centre d'intelligence sur ses clients. De nouvelles missions deviennent possibles : gestion, pilotage, conseil, comparaison sectorielle, détection précoce des difficultés. La donnée, longtemps captive et inexploitable, devient enfin un actif.

7. Pourquoi maintenant

On a beaucoup promis que l'IA transformerait la comptabilité, et on a surtout livré des assistants bavards que personne n'ose laisser décider seuls. Ce n'était pas une question de volonté ni de maturité des équipes. C'était une question d'outil : on tentait de faire décider un modèle entraîné pour convaincre.

L'arrivée d'une catégorie de modèles conçus pour la décision, typés, calibrés, rapides, peu coûteux, et le motif du smart IF qui rend le contrôle au code, change la nature du problème. Les cas d'usage comptables dont on parle depuis des années ne sont plus des démonstrations fragiles. Ils deviennent industrialisables, parce que la fiabilité est enfin portée par l'architecture et non par l'épuisement d'un valideur humain. C'est précisément ce que cherche un cabinet : non pas une promesse de plus, mais un socle sur lequel bâtir sans tout refaire au trimestre suivant.

Nous allons évidemment assister à une prolifération de nouveaux produits, intégrés ou non à des LLM, souvent pour mieux opacifier l'offre et vendre de la puissance au kilo. Mais la voie est clairement celle-ci. Et elle pose une question de fond : avons-nous vraiment besoin d'autant de puissance, d'autant de modèles frontier, de compute à gogo ? Quel sens tout cela a-t-il, in fine, si des modèles spécialisés, directement générateurs de valeur, rendent des décisions rapides et montrent concrètement ce qu'ils apportent à nos entreprises ? La démesure impressionne. L'utile, lui, se mesure.

Je le crois sincèrement : c'est maintenant que les cas d'usage de l'IA appliqués à la comptabilité vont réellement commencer. Pas parce que les modèles sont devenus plus éloquents. Parce qu'ils ont enfin appris à dire, sobrement, de quoi ils sont sûrs.

Questions fréquentes

Qu'est-ce que le smart IF ?

Une couche de décision où un modèle calibré (un modèle System One comme Jev) rend une décision typée assortie d'une confiance, et où le code tranche de façon déterministe : au-dessus d'un seuil il agit automatiquement, en dessous il escalade vers un humain.

Pourquoi les LLM ne sont-ils pas adaptés à la décision comptable ?

Un LLM est entraîné à produire un texte convaincant, pas une décision juste. Il hallucine avec le même aplomb qu'il ait tort ou raison, et ne fournit pas de degré de certitude fiable qu'un logiciel pourrait exploiter.

En quoi le smart IF aide-t-il la comptabilité ?

Il rend fiables des cas d'usage comme la génération d'écriture, le lettrage, la TVA ou la ventilation, et surtout la normalisation des données comptables, qui débloque de nouvelles missions de gestion et de conseil.

Référence : documentation TypeSafe AI, concepts « System One » et « AI primer » (RLCD). docs.typesafe.ai →

← Tous les articles Nous contacter →

← News

Article · AI & accounting

The AI that decides, not the one that chatters: the smart IF enters accounting

by José Vazquez

6 October 2026

The smart IF: a typed decision, a calibrated confidence, and the code that settles it. Above the threshold (0.80), automatic action; below it, escalation to a human.

The AI tools available today are phenomenally powerful. They summarize an inbox in seconds, suggest ready-made replies, write content, produce analyses. The sense of magic is real, and it is deserved.

And yet one question nags, and it has to be asked: where is the productivity gain, the real one, that would justify the cost? Because the cost is not only the subscriptions. It is the organizational change you have to run, the tokens whose bill climbs with usage, an offering that reinvents itself every three months, to the point where you are never sure you bet on the right tool. Summarizing emails, suggesting drafts, writing faster: yes, that is useful. But let us be honest, these uses remain peripheral. They lighten tasks. They do not transform the profession.

I say this from experience, not as a theorist. At Veneen, we offer firms Horalio, an ultra-simplified time-management solution. And yes, it was the combined use of several LLMs that let us build it, simply, efficiently, at a controlled cost. There, AI was a genuine windfall.

But let us ask the real question. Apart from developers, who today can use an LLM to create an application architected enough to be durable and secure? Almost no one. For the software engineer, the LLM is an extraordinary stroke of luck: it multiplies a skill they already have. For everyone else, it produces seductive mock-ups that collapse at the first real edge case. And that is the blind spot of the hype. Apart from IT people, which professionals can honestly say, hand on heart: I have a surplus of value, thanks to AI, that is simply phenomenal? Very few. That is the whole problem, and it is precisely what the smart IF changes for accounting.

For an accounting firm, the calculation is tighter still. A firm needs security, stability, permanence. It lives on reliability, not novelty. Faced with marketing hype that changes its promise every quarter, many firms are paralyzed. And they are right to be. You do not rebuild a regulated organization at the pace of press releases.

I believe this caution is not a lag. It is clear-sightedness. The problem is not that AI lacks power, it is overflowing with it. The problem is that we are asking it the wrong thing.

For we confuse two very different uses under the same word. On one side, writing: summarizing, rephrasing, drafting. On the other, deciding: picking an account, settling an allocation, saying whether two lines reconcile. Large language models are brilliant at the first. They are not built for the second. And it is by confusing them that we wrongly believed they would automate accounting. They will not, not as they are. Another path has just reached maturity, and that is the one that matters.

1. The problem is not that LLMs get it wrong. It is that they get it wrong with confidence.

A word on what an LLM is, without jargon. LLM stands for "large language model." It is an AI trained to produce text by predicting, word after word, the most plausible continuation. It is a machine for writing what sounds right. Not a machine for settling what is right. The nuance seems slim. It is decisive.

An LLM is indeed trained to produce text a human will find convincing. That is precisely its objective, and it is formidably good at it. The flip side is well known: it hallucinates. It invents a reference, a rule, an account number, with the same assurance as when it is right. The tone never betrays the error.

For a writing assistant, that is a manageable flaw. For an accounting decision, it is disqualifying. Accounting does not ask for plausible prose, it asks for a correct decision, and above all a decision whose degree of certainty is known. An LLM reliably gives you neither. It gives you a sentence.

Diogo Almeida, who co-invented reinforcement learning from human feedback (the RLHF that produced ChatGPT), now puts it the other way around at TypeSafe AI: optimizing a model to please a reader rewards sycophancy and confident-sounding hallucinations. Pleasing a human and being trustworthy for software are two different training targets. We spent three years training models for the first, then acted surprised when they failed at the second.

2. The false safeguard: human validation

Faced with this problem, the industry found a reflex answer: put a human in the loop. The LLM proposes, the human validates. Reassuring on paper. Exhausting in practice.

Let us call it by its name, validation fatigue. Ask an employee to check, all day long, the outputs of a machine that is often right but sometimes wrong, without warning, and they end up dropping their guard. Not out of laziness. Out of wear. The first hours, they really check. Then volume wins. They go faster, they validate in batches, they end up validating validations, ticking boxes without truly judging anymore.

The side effects are well known, and heavy:

vigilance dulls precisely where it was meant to protect us: rare errors slip through exactly because they are rare, and no longer expected;
responsibility shifts onto the human without the means to exercise it: they sign off for a machine they cannot truly control;
the work loses its meaning: supervising without deciding, ticking without arbitrating, is no longer a profession, it is a rubber stamp;
mental load rises while perceived value falls. You burn out your best people on the least rewarding task.

So the real question is not "how do we have a human proofread an LLM." It is "how do we obtain a decision whose reliability is carried by the architecture, rather than laid on the shoulders of a human who burns out."

3. Enter Jev, and the class of "System One" models

This is where the arrival of Jev, the model from TypeSafe AI, changes things. Jev is not an improved LLM. It is another species, which TypeSafe calls a "System One" model, after the fast, intuitive thinking described by Daniel Kahneman.

A word on that reference. In "Thinking, Fast and Slow," Daniel Kahneman distinguishes two ways of thinking. System 2 is slow, deliberate, analytical: it is what we call on for a demonstration, a deep analysis, a long chain of reasoning. That is the terrain of LLMs and reasoning models. System 1 is fast, intuitive, almost instantaneous: it is what settles a matter in a fraction of a second, through short decisions with high immediate impact. Day-to-day accounting lives mostly in System 1: thousands of small, reliable, fast, repeated decisions. Jev plays precisely on that ground.

The difference fits in one sentence. Like an LLM, Jev understands natural language. Unlike an LLM, it does not write a reply: it returns a typed decision and a calibrated probability. You do not ask it "what do you think of this invoice?", you ask a question whose space of possible answers you have defined in advance:

a choice (which account, which journal, which category);
a score on a scale (risk level, degree of consistency);
a boolean (do these two lines reconcile, yes or no), with a probability.

And above all, that probability is calibrated. This is the heart of the matter. A calibrated model is one whose probabilities mean something: across all the cases it rates 0.8, roughly 80% turn out correct; across those it rates 0.95, roughly 95%. The probability stops being cosmetic dressing and becomes information software can act on.

To see where this difference comes from, look at three ways of training an AI, which give three results:

RLHF (reinforcement learning from human feedback), training to please a human. You reward the model when its answer pleases. It becomes agreeable, conversational. This is what produced the chatbots, and it is also what rewards, unintentionally, the answer that looks right.
RLVR (reinforcement learning with verifiable rewards), training on verifiable answers. You reward the model when its answer is demonstrably correct, in mathematics for instance. This produced the reasoning models, powerful but slow and expensive.
RLCD (reinforcement learning for calibrated decisions), training for calibrated decisions. This is Jev's path. You do not reward a fine sentence, you reward a correct decision paired with an honest probability. In other words, a model that can not only answer, but also say how sure it is.

Their formula sums up the intent: "building prod, not God." Not a model that does everything and must be watched, but a narrow, fast brick that software can inspect and act on.

4. The smart IF: giving the decision back to the code

It is from this calibration that what I call the smart IF, the intelligent IF, is born. And it is, to my mind, the real conceptual leap.

For sixty years, business software has rested on deterministic rules, hard-coded. If the label contains "EDF," then account 606. Reliable, but dumb. Unable to absorb the infinite variety of accounting reality without turning into an unmanageable forest of rules.

The LLM promised to replace those rules with understanding. But it also replaced the certainty of the rule with the vagueness of a sentence. We gained flexibility, we lost control.

The smart IF reconciles the two. The semantic decision, the one that requires understanding reality, is entrusted to a calibrated model. Control stays with the code. Concretely: the model returns a decision and a confidence, and the software decides what to do with it, deterministically. If confidence exceeds a threshold, it acts automatically. Below it, it escalates to a human. The rule does not disappear, it becomes intelligent: it no longer keys on a word, it keys on a measured degree of certainty.

Validation fatigue collapses on its own. The human no longer validates everything, they only see the genuinely uncertain cases, the ones the architecture has flagged as such. In an accounting flow, the share of high-confidence cases is overwhelming. Human judgment is finally reallocated where it adds value, and withdrawn from where it was burning out.

Jev remains probabilistic, I do not deny it. But its reliability does not rest on the hope that it is right. It rests on its architecture and its pre-calibration. Calibrated on an accounting base (a chart of accounts, a national accounting standard, a history of entries, an audit file of entries), a model of this kind does not guess in a void: it decides inside a known frame, and it can say when it is unsure. That is a real advance, not one more marketing promise. And it is exactly the kind of base, stable and verifiable, that a firm can adopt without betraying itself.

5. The accounting use cases, at last

What used to stumble on hallucination becomes practicable:

entry generation, proposed with a confidence level, posted automatically above the threshold, submitted below it;
reconciliation, framed as a calibrated boolean rather than a rigid rule or a gamble;
VAT, whose rate and allocation become a typed, traceable decision, not a sentence to proofread;
consistency control, continuously scoring deviation from the norm and surfacing what falls outside the frame;
analytical allocation, long deemed irreducible to rules, finally approachable as a calibrated choice.

All of this is useful. But that, in my view, is not where the essential plays out.

6. The real bottleneck: data normalization

There is a difficulty the whole profession knows and no one talks about, because it is thankless: accounting data is not normalized. Every company has its own chart of accounts, its in-house labels, its habits, its legacies. The same purchase sits in ten different accounts depending on the file. Labels are a mush of abbreviations. From one client to the next, the data says the same thing in a different language.

This is the bottleneck that quietly sank nearly every promise to exploit accounting data. You cannot compare, aggregate, model, or advise on data that does not speak the same language. Sector benchmarking, steering, data-driven management advice: all of it hits normalization before it even begins.

We can see, in fact, the fashionable answer blooming everywhere: the data lake. Some vendors propose to pour all accounting data into a large lake, then plug in panels, dashboards, comparisons, presented as the optimum of data exploitation. The idea is seductive, but it puts the cart before the horse. A data lake does not remove the dirt, it stores it at greater scale. If the data entering it is not normalized, the panel aggregates apples and oranges behind a handsome interface. We pile up data where we first needed to make it speak the same language. The lake is only worth as much as the normalization upstream. And that is exactly the missing layer.

This is precisely what a System One model can do, and this is where I place the major advance. To normalize is fundamentally to classify: attach a grubby label to the right normalized line, map an idiosyncratic chart of accounts onto a common standard, bring heterogeneous entries back to a stable category. These are exactly typed, calibrated decisions. Not writing. Classification, at scale, at a trivial cost, with a confidence level on every match.

Normalizing accounting data reliably unlocks everything that comes after. Once the data of thousands of files speaks the same language, the firm stops being a center for producing entries and becomes a center of intelligence about its clients. New engagements become possible: management, steering, advice, sector comparison, early detection of distress. The data, long captive and unusable, finally becomes an asset.

7. Why now

Much was promised that AI would transform accounting, and what was mostly delivered were chatty assistants no one dares let decide alone. It was not a matter of willingness or of team maturity. It was a matter of tool: we were trying to make a model trained to convince do the deciding.

The arrival of a class of models built for decision, typed, calibrated, fast, cheap, and the smart IF pattern that gives control back to the code, changes the nature of the problem. The accounting use cases we have discussed for years are no longer fragile demos. They become industrializable, because reliability is finally carried by the architecture and not by the exhaustion of a human validator. That is exactly what a firm is looking for: not one more promise, but a base to build on without redoing everything the following quarter.

We will of course witness a proliferation of new products, integrated with LLMs or not, often to better obscure the offering and sell power by the pound. But the path is clearly this one. And it raises a fundamental question: do we really need so much power, so many frontier models, so much compute on tap? What does all of it mean, in the end, if specialized models, directly generating value, return fast decisions and show concretely what they bring to our companies? Excess impresses. Usefulness, by contrast, can be measured.

I sincerely believe it: it is now that AI use cases applied to accounting will truly begin. Not because the models have grown more eloquent. Because they have finally learned to say, soberly, what they are sure of.

Frequently asked questions

What is the smart IF?

A decision layer where a calibrated model (a System One model such as Jev) returns a typed decision with a confidence, and where the code settles it deterministically: above a threshold it acts automatically, below it it escalates to a human.

Why are LLMs not suited to accounting decisions?

An LLM is trained to produce convincing text, not a correct decision. It hallucinates with the same assurance whether it is right or wrong, and does not provide a reliable degree of certainty that software could act on.

How does the smart IF help accounting?

It makes use cases such as entry generation, reconciliation, VAT or allocation reliable, and above all the normalization of accounting data, which unlocks new management and advisory engagements.

Reference: TypeSafe AI documentation, "System One" and "AI primer" concepts (RLCD). docs.typesafe.ai →

← All articles Contact us →

← News

Artículo · IA y contabilidad

La IA que decide, no la que parlotea: el smart IF entra en la contabilidad

por José Vazquez

6 de octubre de 2026

El smart IF: una decisión tipada, una confianza calibrada, y el código que zanja. Por encima del umbral (0,80), acción automática; por debajo, escalado a un humano.

Las herramientas de IA disponibles hoy son de una potencia fenomenal. Resumen una bandeja de entrada en segundos, proponen respuestas ya hechas, redactan contenidos, producen análisis. La sensación de magia es real, y es merecida.

Y sin embargo, una pregunta incomoda, y hay que atreverse a plantearla: ¿dónde está la ganancia de productividad, la de verdad, la que justificaría el coste? Porque el coste no es solo el de las suscripciones. Es el cambio de organización que hay que conducir, son los tokens cuya factura sube con el uso, es una oferta que se reinventa cada tres meses, hasta el punto de que nunca se está seguro de haber apostado por la herramienta correcta. Resumir correos, proponer borradores, redactar más rápido: sí, es útil. Pero seamos sinceros, estos usos siguen siendo periféricos. Aligeran tareas. No transforman la profesión.

Lo digo por experiencia, no como teórico. En Veneen ofrecemos a los despachos Horalio, una solución ultra-simplificada de gestión del tiempo. Y sí, fue el uso combinado de varios LLM lo que nos permitió producirla, de forma simple, eficaz, a un coste controlado. Ahí, la IA fue una verdadera baza.

Pero planteemos la verdadera pregunta. Aparte de los desarrolladores, ¿quién puede hoy crear, con un LLM, una aplicación lo bastante arquitecturada para ser perenne y segura? Casi nadie. Para el informático, el LLM es una suerte inaudita: multiplica un saber hacer que ya posee. Para los demás, produce maquetas seductoras que se derrumban al primer caso límite real. Y ahí está el punto ciego de la hype. Aparte de los informáticos, ¿qué profesionales pueden decir honestamente, con la mano en el corazón: tengo un plus de valor, gracias a la IA, que es sencillamente fenomenal? Muy pocos. Ese es todo el problema, y es precisamente lo que el smart IF viene a cambiar para la contabilidad.

Para una sociedad de expertos contables, el cálculo es aún más estrecho. Un despacho necesita seguridad, estabilidad, permanencia. Vive de la fiabilidad, no de la novedad. Ante una hype de marketing que cambia de promesa cada trimestre, muchos despachos están paralizados. Y tienen razón en estarlo. No se rehace una organización regulada al ritmo de los anuncios.

Creo que esta prudencia no es un retraso. Es lucidez. El problema no es que a la IA le falte potencia, le sobra. El problema es que le pedimos lo que no debemos.

Porque confundimos dos usos muy distintos bajo la misma palabra. Por un lado, escribir: resumir, reformular, redactar. Por otro, decidir: elegir una cuenta, zanjar una imputación, decir si dos líneas se concilian. Los grandes modelos de lenguaje son brillantes en lo primero. No están hechos para lo segundo. Y es al confundirlos como creímos, erróneamente, que iban a automatizar la contabilidad. No lo harán, no tal como están. Otra vía acaba de alcanzar su madurez, y es la que cuenta.

1. El problema no es que los LLM se equivoquen. Es que se equivocan con aplomo.

Una palabra sobre qué es un LLM, sin jerga. LLM significa «large language model», gran modelo de lenguaje. Es una IA entrenada para producir texto prediciendo, palabra tras palabra, la continuación más plausible. Es una máquina de escribir lo que suena bien. No una máquina de zanjar lo que es correcto. El matiz parece fino. Es decisivo.

Un LLM está, en efecto, entrenado para producir un texto que un humano juzgará convincente. Es exactamente su objetivo, y es tremendamente bueno en ello. El reverso es conocido: alucina. Inventa una referencia, una regla, un número de cuenta, con la misma seguridad que cuando acierta. El tono nunca delata el error.

Para un asistente de redacción, es un defecto manejable. Para una decisión contable, es descalificador. La contabilidad no pide una prosa plausible, pide una decisión correcta, y sobre todo una decisión cuyo grado de certeza se conozca. Un LLM no le da ni lo uno ni lo otro de forma fiable. Le da una frase.

Diogo Almeida, que co-inventó el aprendizaje por refuerzo sobre preferencias humanas (la RLHF que dio ChatGPT), lo formula hoy al revés en TypeSafe AI: optimizar un modelo para agradar a un lector premia la adulación y las alucinaciones que suenan bien. Agradar a un humano y ser fiable para un software son dos objetivos de entrenamiento distintos. Pasamos tres años entrenando modelos para el primero, y luego nos sorprendió que fallaran en el segundo.

2. La falsa salvaguarda: hacer validar por un humano

Ante este problema, la industria encontró una respuesta refleja: poner un humano en el bucle. El LLM propone, el humano valida. Tranquilizador sobre el papel. Agotador en los hechos.

Llamémoslo por su nombre, la fatiga de validación. Pida a un colaborador que controle, durante todo el día, las salidas de una máquina que acierta a menudo pero a veces se equivoca, sin avisar, y acabará bajando la guardia. No por pereza. Por desgaste. Las primeras horas verifica de verdad. Luego el volumen se impone. Va más rápido, valida por lotes, acaba validando validaciones, marcando casillas sin juzgar ya realmente.

Los efectos secundarios son conocidos, y pesados:

la vigilancia se embota justo donde debía protegernos: los errores raros pasan precisamente porque son raros, y ya no se esperan;
la responsabilidad se desplaza sobre el humano sin darle los medios: firma por una máquina que no puede controlar de verdad;
el trabajo pierde su sentido: supervisar sin decidir, marcar sin arbitrar, ya no es una profesión, es un sello;
la carga mental sube mientras el valor percibido baja. Se agota a los mejores perfiles en la tarea menos gratificante.

El verdadero asunto no es, pues, «cómo hacer que un humano relea un LLM». Es «cómo obtener una decisión cuya fiabilidad la sostenga la arquitectura, y no recaiga sobre los hombros de un humano que se agota».

3. Entra en escena Jev, y la categoría de los modelos «System One»

Aquí es donde la llegada de Jev, el modelo de TypeSafe AI, cambia las reglas. Jev no es un LLM mejorado. Es otra especie, que TypeSafe llama un modelo «System One», en referencia al pensamiento rápido e intuitivo descrito por Daniel Kahneman.

Una palabra sobre esta referencia. En «Pensar rápido, pensar despacio», Daniel Kahneman distingue dos formas de pensar. El Sistema 2 es lento, deliberado, analítico: es el que se solicita para una demostración, un análisis profundo, un razonamiento largo. Es el terreno de los LLM y de los modelos de razonamiento. El Sistema 1 es rápido, intuitivo, casi instantáneo: es el que zanja en una fracción de segundo, mediante decisiones cortas pero de fuerte impacto inmediato. La contabilidad cotidiana vive sobre todo en el Sistema 1: miles de pequeñas decisiones seguras, rápidas, repetidas. Jev juega precisamente en ese terreno.

La diferencia cabe en una frase. Como un LLM, Jev comprende el lenguaje natural. A diferencia de un LLM, no redacta una respuesta: devuelve una decisión tipada y una probabilidad calibrada. No le pregunta «¿qué opinas de esta factura?», le plantea una pregunta cuyo espacio de respuestas posibles usted ha definido de antemano:

una elección (qué cuenta, qué diario, qué categoría);
una puntuación en una escala (nivel de riesgo, grado de coherencia);
un booleano (¿se concilian estas dos líneas, sí o no?), acompañado de una probabilidad.

Y sobre todo, esa probabilidad está calibrada. Es el núcleo del asunto. Un modelo calibrado es aquel cuyas probabilidades significan algo: del conjunto de casos a los que asigna 0,8, cerca del 80 % resultan correctos; de aquellos a los que asigna 0,95, cerca del 95 %. La probabilidad deja de ser un adorno cosmético para convertirse en información que el código puede aprovechar.

Para entender de dónde viene esta diferencia, hay que mirar tres formas de entrenar una IA, que dan tres resultados:

RLHF (reinforcement learning from human feedback, aprendizaje por refuerzo a partir de retornos humanos), el entrenamiento para agradar a un humano. Se premia al modelo cuando su respuesta agrada. Se vuelve agradable, conversacional. Es lo que dio los chatbots, y es también lo que premia, sin quererlo, la respuesta que parece correcta.
RLVR (reinforcement learning with verifiable rewards, aprendizaje por refuerzo con recompensas verificables), el entrenamiento sobre respuestas verificables. Se premia al modelo cuando su respuesta es demostrablemente correcta, por ejemplo en matemáticas. Dio los modelos de razonamiento, potentes pero lentos y costosos.
RLCD (reinforcement learning for calibrated decisions, aprendizaje por refuerzo para decisiones calibradas), el entrenamiento para decisiones calibradas. Es la vía de Jev. No se premia una bella frase, se premia una decisión correcta acompañada de una probabilidad honesta. Dicho de otro modo, un modelo que no solo sabe responder, sino también decir hasta qué punto está seguro.

Su fórmula resume la intención: «construir producción, no un dios». No un modelo que lo hace todo y hay que vigilar, sino una pieza estrecha, rápida, que el software puede inspeccionar y sobre la que puede actuar.

4. El smart IF: devolver la decisión al código

De esa calibración nace lo que llamo el smart IF, el IF inteligente. Y es, a mi juicio, el verdadero salto conceptual.

Durante sesenta años, el software de gestión ha reposado sobre reglas deterministas, escritas a mano. Si el concepto contiene «EDF», entonces cuenta 606. Fiable, pero tonto. Incapaz de absorber la variedad infinita de la realidad contable sin convertirse en un bosque de reglas inmanejable.

El LLM prometía reemplazar esas reglas por comprensión. Pero también reemplazaba la certeza de la regla por la vaguedad de una frase. Ganábamos flexibilidad, perdíamos control.

El smart IF reconcilia ambos. La decisión semántica, la que exige comprender lo real, se confía a un modelo calibrado. El control se queda en el código. En concreto: el modelo devuelve una decisión y una confianza, y el software decide qué hacer con ello, de forma determinista. Si la confianza supera un umbral, se actúa automáticamente. Por debajo, se escala a un humano. La regla no desaparece, se vuelve inteligente: ya no se basa en una palabra clave, se basa en un grado de certeza medido.

La fatiga de validación se desploma por sí sola. El humano ya no valida todo, solo ve los casos realmente inciertos, los que la arquitectura ha señalado como tales. En un flujo contable, la proporción de casos de alta confianza es abrumadora. El juicio humano se reasigna por fin donde aporta valor, y se retira de donde se agotaba.

Jev sigue siendo probabilístico, no lo niego. Pero su fiabilidad no reposa en la esperanza de que acierte. Reposa en su arquitectura y en su pre-calibrado. Calibrado sobre una base contable (un plan de cuentas, un marco contable nacional, un histórico de asientos, un archivo de asientos), un modelo de este tipo no adivina en el vacío: decide dentro de un marco conocido, y sabe decir cuándo no está seguro. Es un avance real, no una promesa de marketing más. Y es exactamente el tipo de base, estable y verificable, que un despacho puede adoptar sin renunciar a sí mismo.

5. Los casos de uso contables, por fin

Lo que ayer tropezaba con la alucinación se vuelve practicable:

la generación de asientos, propuesta con un nivel de confianza, registrada automáticamente por encima del umbral, sometida por debajo;
la conciliación, planteada como un booleano calibrado en lugar de una regla rígida o una apuesta;
el IVA, cuyo tipo e imputación se vuelven una decisión tipada y trazable, no una frase que releer;
el control de coherencia, que puntúa en continuo la desviación respecto a la norma y hace emerger lo que sale del marco;
la imputación analítica, largo tiempo tenida por irreducible a reglas, por fin abordable como una elección calibrada.

Todo esto es útil. Pero no es ahí, a mi parecer, donde se juega lo esencial.

6. El verdadero cuello de botella: la normalización de los datos

Existe una dificultad que toda la profesión conoce y de la que nadie habla, porque es ingrata: los datos contables no están normalizados. Cada empresa tiene su plan de cuentas, sus conceptos caseros, sus costumbres, sus herencias. Una misma compra se aloja en diez cuentas distintas según el expediente. Los conceptos son una papilla de abreviaturas. De un cliente a otro, el dato dice lo mismo en un idioma diferente.

Es el cuello de botella que hundió, discretamente, casi todas las promesas de explotación del dato contable. No se puede comparar, agregar, modelizar ni asesorar sobre datos que no hablan el mismo idioma. El benchmark sectorial, el pilotaje, el asesoramiento de gestión basado en datos: todo ello choca con la normalización antes incluso de empezar.

Se ve, de hecho, florecer la respuesta de moda: el data lake. Algunos editores proponen volcar todos los datos contables en un gran lago de datos, y luego conectar panels, cuadros de mando, comparaciones, presentados como el óptimo de la explotación del dato. La idea es seductora, pero pone el carro delante de los bueyes. Un data lake no quita la suciedad, la almacena a mayor escala. Si los datos que entran no están normalizados, el panel agrega peras con manzanas tras una bonita interfaz. Se apila dato donde primero había que hacerlo hablar el mismo idioma. El lago solo vale lo que vale la normalización aguas arriba. Y esa es precisamente la capa que falta.

Es precisamente lo que un modelo de tipo System One sabe hacer, y ahí sitúo el avance mayor. Normalizar es, en el fondo, clasificar: vincular un concepto sucio a la partida normalizada correcta, mapear un plan de cuentas idiosincrásico sobre un marco común, reconducir asientos heterogéneos a una categoría estable. Son exactamente decisiones tipadas y calibradas. No redacción. Clasificación, a gran escala, a un coste irrisorio, con un grado de confianza sobre cada vínculo.

Normalizar el dato contable de forma fiable desbloquea todo lo que viene después. Una vez que los datos de miles de expedientes hablan el mismo idioma, el despacho deja de ser un centro de producción de asientos para convertirse en un centro de inteligencia sobre sus clientes. Nuevas misiones se vuelven posibles: gestión, pilotaje, asesoramiento, comparación sectorial, detección precoz de dificultades. El dato, largo tiempo cautivo e inexplotable, se convierte por fin en un activo.

7. Por qué ahora

Se prometió mucho que la IA transformaría la contabilidad, y lo que se entregó fueron sobre todo asistentes parlanchines que nadie se atreve a dejar decidir solos. No era una cuestión de voluntad ni de madurez de los equipos. Era una cuestión de herramienta: se intentaba hacer decidir a un modelo entrenado para convencer.

La llegada de una categoría de modelos concebidos para la decisión, tipados, calibrados, rápidos, baratos, y el patrón del smart IF que devuelve el control al código, cambia la naturaleza del problema. Los casos de uso contables de los que se habla desde hace años dejan de ser demostraciones frágiles. Se vuelven industrializables, porque la fiabilidad la sostiene por fin la arquitectura y no el agotamiento de un validador humano. Es precisamente lo que busca un despacho: no una promesa más, sino una base sobre la que construir sin rehacerlo todo al trimestre siguiente.

Asistiremos, por supuesto, a una proliferación de nuevos productos, integrados o no a LLM, a menudo para opacar mejor la oferta y vender potencia al kilo. Pero la vía es claramente esta. Y plantea una pregunta de fondo: ¿necesitamos realmente tanta potencia, tantos modelos frontier, tanto compute a mansalva? ¿Qué sentido tiene todo esto, a fin de cuentas, si modelos especializados, directamente generadores de valor, devuelven decisiones rápidas y muestran concretamente lo que aportan a nuestras empresas? La desmesura impresiona. Lo útil, en cambio, se mide.

Lo creo sinceramente: es ahora cuando los casos de uso de la IA aplicados a la contabilidad van a empezar de verdad. No porque los modelos se hayan vuelto más elocuentes. Porque por fin han aprendido a decir, con sobriedad, de qué están seguros.

Preguntas frecuentes

¿Qué es el smart IF?

Una capa de decisión donde un modelo calibrado (un modelo System One como Jev) devuelve una decisión tipada acompañada de una confianza, y donde el código zanja de forma determinista: por encima de un umbral actúa automáticamente, por debajo escala a un humano.

¿Por qué los LLM no son adecuados para la decisión contable?

Un LLM está entrenado para producir un texto convincente, no una decisión correcta. Alucina con el mismo aplomo tenga razón o no, y no aporta un grado de certeza fiable que un software pudiera aprovechar.

¿En qué ayuda el smart IF a la contabilidad?

Hace fiables casos de uso como la generación de asientos, la conciliación, el IVA o la imputación, y sobre todo la normalización de los datos contables, que desbloquea nuevas misiones de gestión y asesoramiento.

Referencia: documentación de TypeSafe AI, conceptos «System One» y «AI primer» (RLCD). docs.typesafe.ai →

← Todos los artículos Contáctenos →

← News

Artigo · IA e contabilidade

A IA que decide, não a que tagarela: o smart IF entra na contabilidade

por José Vazquez

6 de outubro de 2026

O smart IF: uma decisão tipada, uma confiança calibrada, e o código que resolve. Acima do limiar (0,80), ação automática; abaixo, escalada para um humano.

As ferramentas de IA disponíveis hoje são de uma potência fenomenal. Resumem uma caixa de correio em segundos, propõem respostas já prontas, redigem conteúdos, produzem análises. A sensação de magia é real, e é merecida.

E no entanto, uma pergunta incomoda, e é preciso ousar fazê-la: onde está o ganho de produtividade, o verdadeiro, aquele que justificaria o custo? Porque o custo não é apenas o das subscrições. É a mudança de organização que é preciso conduzir, são os tokens cuja fatura sobe com o uso, é uma oferta que se reinventa de três em três meses, ao ponto de nunca se ter a certeza de ter apostado na ferramenta certa. Resumir emails, propor rascunhos, redigir mais depressa: sim, é útil. Mas sejamos sinceros, estes usos continuam periféricos. Aliviam tarefas. Não transformam a profissão.

Digo-o por experiência, não como teórico. Na Veneen propomos aos gabinetes o Horalio, uma solução ultra-simplificada de gestão do tempo. E sim, foi o uso combinado de vários LLM que nos permitiu produzi-la, de forma simples, eficaz, a um custo controlado. Aí, a IA foi uma verdadeira dádiva.

Mas coloquemos a verdadeira pergunta. Além dos programadores, quem pode hoje criar, com um LLM, uma aplicação suficientemente arquitetada para ser perene e segura? Quase ninguém. Para o informático, o LLM é uma sorte inaudita: multiplica um saber-fazer que já possui. Para os outros, produz maquetes sedutoras que se desmoronam ao primeiro verdadeiro caso-limite. E é aí que está o ponto cego da hype. Além dos informáticos, que profissionais podem dizer honestamente, de mão no peito: tenho um acréscimo de valor, graças à IA, que é simplesmente fenomenal? Muito poucos. É esse o problema todo, e é precisamente o que o smart IF vem mudar para a contabilidade.

Para uma sociedade de contabilidade, a conta é ainda mais apertada. Um gabinete precisa de segurança, de estabilidade, de permanência. Vive da fiabilidade, não da novidade. Perante uma hype de marketing que muda de promessa a cada trimestre, muitos gabinetes estão paralisados. E têm razão em estar. Não se refaz uma organização regulada ao ritmo dos anúncios.

Creio que esta prudência não é um atraso. É lucidez. O problema não é que à IA falte potência, transborda dela. O problema é que lhe pedimos a coisa errada.

Pois confundimos dois usos muito diferentes sob a mesma palavra. De um lado, escrever: resumir, reformular, redigir. Do outro, decidir: escolher uma conta, resolver uma imputação, dizer se duas linhas se conciliam. Os grandes modelos de linguagem são brilhantes no primeiro. Não foram feitos para o segundo. E foi ao confundi-los que acreditámos, erradamente, que iriam automatizar a contabilidade. Não o farão, não como estão. Outra via acaba de atingir a maturidade, e é ela que conta.

1. O problema não é que os LLM errem. É que erram com desembaraço.

Uma palavra sobre o que é um LLM, sem jargão. LLM quer dizer «large language model», grande modelo de linguagem. É uma IA treinada para produzir texto prevendo, palavra após palavra, a continuação mais plausível. É uma máquina de escrever o que soa bem. Não uma máquina de resolver o que está certo. A nuance parece ténue. É decisiva.

Um LLM é, com efeito, treinado para produzir um texto que um humano julgará convincente. É exatamente o seu objetivo, e é tremendamente bom nisso. O reverso é conhecido: alucina. Inventa uma referência, uma regra, um número de conta, com a mesma segurança de quando acerta. O tom nunca trai o erro.

Para um assistente de redação, é um defeito gerível. Para uma decisão contabilística, é desqualificante. A contabilidade não pede uma prosa plausível, pede uma decisão correta, e sobretudo uma decisão cujo grau de certeza se conheça. Um LLM não lhe dá nem uma coisa nem outra de forma fiável. Dá-lhe uma frase.

Diogo Almeida, que co-inventou a aprendizagem por reforço sobre preferências humanas (a RLHF que deu o ChatGPT), formula-o hoje ao contrário na TypeSafe AI: otimizar um modelo para agradar a um leitor recompensa a bajulação e as alucinações que soam bem. Agradar a um humano e ser digno de confiança para um software são dois objetivos de treino diferentes. Passámos três anos a treinar modelos para o primeiro, e depois estranhámos que falhassem no segundo.

2. A falsa salvaguarda: fazer validar por um humano

Perante este problema, a indústria encontrou uma resposta reflexa: pôr um humano no ciclo. O LLM propõe, o humano valida. Tranquilizador no papel. Exaustivo nos factos.

Chamemos-lhe pelo nome, a fadiga de validação. Peça a um colaborador que controle, o dia inteiro, as saídas de uma máquina que acerta muitas vezes mas às vezes erra, sem avisar, e acabará por baixar a guarda. Não por preguiça. Por desgaste. As primeiras horas, verifica a sério. Depois o volume impõe-se. Vai mais depressa, valida por lotes, acaba por validar validações, a marcar sem já julgar verdadeiramente.

Os efeitos colaterais são conhecidos, e pesados:

a vigilância embota-se precisamente onde devia proteger-nos: os erros raros passam justamente porque são raros, e já não são esperados;
a responsabilidade desliza para o humano sem lhe dar os meios: assina por uma máquina que não pode verdadeiramente controlar;
o trabalho perde o sentido: supervisionar sem decidir, marcar sem arbitrar, já não é uma profissão, é um carimbo;
a carga mental sobe enquanto o valor percebido desce. Esgotam-se os melhores perfis na tarefa menos gratificante.

A verdadeira questão não é, pois, «como fazer um humano reler um LLM». É «como obter uma decisão cuja fiabilidade seja sustentada pela arquitetura, e não assente sobre os ombros de um humano que se esgota».

3. Entra em cena Jev, e a categoria dos modelos «System One»

É aqui que a chegada de Jev, o modelo da TypeSafe AI, muda o jogo. Jev não é um LLM melhorado. É outra espécie, a que a TypeSafe chama um modelo «System One», em referência ao pensamento rápido e intuitivo descrito por Daniel Kahneman.

Uma palavra sobre esta referência. Em «Pensar, Depressa e Devagar», Daniel Kahneman distingue duas formas de pensar. O Sistema 2 é lento, deliberado, analítico: é o que se solicita para uma demonstração, uma análise aprofundada, um raciocínio longo. É o terreno dos LLM e dos modelos de raciocínio. O Sistema 1 é rápido, intuitivo, quase instantâneo: é o que resolve numa fração de segundo, através de decisões curtas mas de forte impacto imediato. A contabilidade quotidiana vive sobretudo no Sistema 1: milhares de pequenas decisões seguras, rápidas, repetidas. Jev joga precisamente nesse terreno.

A diferença cabe numa frase. Como um LLM, Jev compreende a linguagem natural. Ao contrário de um LLM, não redige uma resposta: devolve uma decisão tipada e uma probabilidade calibrada. Não lhe pergunta «o que achas desta fatura?», coloca-lhe uma pergunta cujo espaço de respostas possíveis definiu de antemão:

uma escolha (que conta, que diário, que categoria);
uma pontuação numa escala (nível de risco, grau de coerência);
um booleano (estas duas linhas conciliam-se, sim ou não?), acompanhado de uma probabilidade.

E sobretudo, essa probabilidade é calibrada. É o cerne do assunto. Um modelo calibrado é aquele cujas probabilidades significam alguma coisa: do conjunto de casos a que atribui 0,8, cerca de 80 % revelam-se corretos; dos que atribui 0,95, cerca de 95 %. A probabilidade deixa de ser um adorno cosmético para se tornar informação que o código pode aproveitar.

Para compreender de onde vem esta diferença, é preciso olhar para três formas de treinar uma IA, que dão três resultados:

RLHF (reinforcement learning from human feedback, aprendizagem por reforço a partir de retornos humanos), o treino para agradar a um humano. Recompensa-se o modelo quando a sua resposta agrada. Torna-se agradável, conversacional. É o que deu os chatbots, e é também o que recompensa, sem querer, a resposta que parece certa.
RLVR (reinforcement learning with verifiable rewards, aprendizagem por reforço com recompensas verificáveis), o treino sobre respostas verificáveis. Recompensa-se o modelo quando a sua resposta é demonstravelmente correta, por exemplo em matemática. Deu os modelos de raciocínio, potentes mas lentos e dispendiosos.
RLCD (reinforcement learning for calibrated decisions, aprendizagem por reforço para decisões calibradas), o treino para decisões calibradas. É a via de Jev. Não se recompensa uma bela frase, recompensa-se uma decisão correta acompanhada de uma probabilidade honesta. Por outras palavras, um modelo que não só sabe responder, mas também dizer até que ponto está seguro.

A sua fórmula resume a intenção: «construir produção, não um deus». Não um modelo que faz tudo e tem de ser vigiado, mas uma peça estreita, rápida, que o software pode inspecionar e sobre a qual pode agir.

4. O smart IF: devolver a decisão ao código

É dessa calibração que nasce aquilo a que chamo o smart IF, o IF inteligente. E é, a meu ver, o verdadeiro salto conceptual.

Durante sessenta anos, o software de gestão assentou em regras deterministas, escritas à mão. Se o descritivo contém «EDF», então conta 606. Fiável, mas tolo. Incapaz de absorver a variedade infinita da realidade contabilística sem se tornar uma floresta de regras ingerível.

O LLM prometia substituir essas regras por compreensão. Mas substituía também a certeza da regra pela vagueza de uma frase. Ganhávamos flexibilidade, perdíamos controlo.

O smart IF reconcilia os dois. A decisão semântica, a que exige compreender o real, é confiada a um modelo calibrado. O controlo fica no código. Em concreto: o modelo devolve uma decisão e uma confiança, e o software decide o que fazer com isso, de forma determinista. Se a confiança ultrapassa um limiar, age-se automaticamente. Abaixo, escala-se para um humano. A regra não desaparece, torna-se inteligente: já não assenta numa palavra-chave, assenta num grau de certeza medido.

A fadiga de validação desmorona-se por si só. O humano já não valida tudo, só vê os casos realmente incertos, aqueles que a arquitetura assinalou como tais. Num fluxo contabilístico, a proporção de casos de alta confiança é esmagadora. O juízo humano é por fim realocado onde acrescenta valor, e retirado de onde se esgotava.

Jev continua probabilístico, não o nego. Mas a sua fiabilidade não assenta na esperança de que acerte. Assenta na sua arquitetura e no seu pré-calibramento. Calibrado sobre uma base contabilística (um plano de contas, um referencial contabilístico nacional, um histórico de lançamentos, um ficheiro de lançamentos), um modelo deste tipo não adivinha no vazio: decide dentro de um quadro conhecido, e sabe dizer quando não está seguro. É um avanço real, não mais uma promessa de marketing. E é exatamente o tipo de base, estável e verificável, que um gabinete pode adotar sem se renegar.

5. Os casos de uso contabilísticos, enfim

O que ontem tropeçava na alucinação torna-se praticável:

a geração de lançamentos, proposta com um nível de confiança, registada automaticamente acima do limiar, submetida abaixo;
a conciliação, colocada como um booleano calibrado em vez de uma regra rígida ou de uma aposta;
o IVA, cuja taxa e imputação se tornam uma decisão tipada e rastreável, não uma frase para reler;
o controlo de coerência, que pontua em contínuo o desvio face à norma e faz emergir o que sai do quadro;
a imputação analítica, longamente tida por irredutível à regra, enfim abordável como uma escolha calibrada.

Tudo isto é útil. Mas não é aí, a meu ver, que se joga o essencial.

6. O verdadeiro estrangulamento: a normalização dos dados

Existe uma dificuldade que toda a profissão conhece e de que ninguém fala, porque é ingrata: os dados contabilísticos não estão normalizados. Cada empresa tem o seu plano de contas, os seus descritivos caseiros, os seus hábitos, as suas heranças. Uma mesma compra fica alojada em dez contas diferentes consoante o dossiê. Os descritivos são uma papa de abreviaturas. De um cliente para o outro, o dado diz a mesma coisa numa língua diferente.

É o estrangulamento que afundou, discretamente, quase todas as promessas de exploração do dado contabilístico. Não se pode comparar, agregar, modelizar nem aconselhar sobre dados que não falam a mesma língua. O benchmark setorial, o pilotar, o conselho de gestão baseado em dados: tudo isso embate na normalização antes mesmo de começar.

Vê-se, aliás, florescer a resposta da moda: o data lake. Alguns editores propõem despejar todos os dados contabilísticos num grande lago de dados, e depois ligar-lhe panels, painéis, comparações, apresentados como o ótimo da exploração do dado. A ideia é sedutora, mas põe o carro à frente dos bois. Um data lake não tira a sujidade, armazena-a em maior escala. Se os dados que entram não estão normalizados, o painel agrega alhos com bugalhos por trás de uma bela interface. Empilha-se dado onde primeiro era preciso fazê-lo falar a mesma língua. O lago só vale o que vale a normalização a montante. E é precisamente essa a camada que falta.

É precisamente o que um modelo do tipo System One sabe fazer, e é aí que situo o avanço maior. Normalizar é, no fundo, classificar: ligar um descritivo sujo à rubrica normalizada certa, mapear um plano de contas idiossincrático sobre um referencial comum, reconduzir lançamentos heterogéneos a uma categoria estável. São exatamente decisões tipadas e calibradas. Não redação. Classificação, em larga escala, a um custo irrisório, com um grau de confiança sobre cada ligação.

Normalizar o dado contabilístico de forma fiável desbloqueia tudo o que vem depois. Uma vez que os dados de milhares de dossiês falam a mesma língua, o gabinete deixa de ser um centro de produção de lançamentos para se tornar um centro de inteligência sobre os seus clientes. Novas missões tornam-se possíveis: gestão, pilotagem, conselho, comparação setorial, deteção precoce de dificuldades. O dado, longamente cativo e inexplorável, torna-se enfim um ativo.

7. Porquê agora

Prometeu-se muito que a IA transformaria a contabilidade, e o que se entregou foram sobretudo assistentes faladores que ninguém ousa deixar decidir sozinhos. Não era uma questão de vontade nem de maturidade das equipas. Era uma questão de ferramenta: tentava-se fazer decidir um modelo treinado para convencer.

A chegada de uma categoria de modelos concebidos para a decisão, tipados, calibrados, rápidos, baratos, e o padrão do smart IF que devolve o controlo ao código, muda a natureza do problema. Os casos de uso contabilísticos de que se fala há anos deixam de ser demonstrações frágeis. Tornam-se industrializáveis, porque a fiabilidade é por fim sustentada pela arquitetura e não pelo esgotamento de um validador humano. É precisamente o que um gabinete procura: não mais uma promessa, mas uma base sobre a qual construir sem refazer tudo no trimestre seguinte.

Assistiremos, claro, a uma proliferação de novos produtos, integrados ou não a LLM, muitas vezes para opacificar melhor a oferta e vender potência ao quilo. Mas a via é claramente esta. E coloca uma questão de fundo: precisamos realmente de tanta potência, de tantos modelos frontier, de tanto compute à farta? Que sentido tem tudo isto, no fim de contas, se modelos especializados, diretamente geradores de valor, devolvem decisões rápidas e mostram concretamente o que trazem às nossas empresas? O excesso impressiona. O útil, esse, mede-se.

Acredito-o sinceramente: é agora que os casos de uso da IA aplicados à contabilidade vão realmente começar. Não porque os modelos se tenham tornado mais eloquentes. Porque aprenderam por fim a dizer, com sobriedade, do que estão seguros.

Perguntas frequentes

O que é o smart IF?

Uma camada de decisão onde um modelo calibrado (um modelo System One como Jev) devolve uma decisão tipada acompanhada de uma confiança, e onde o código resolve de forma determinista: acima de um limiar age automaticamente, abaixo escala para um humano.

Porque é que os LLM não são adequados à decisão contabilística?

Um LLM é treinado para produzir um texto convincente, não uma decisão correta. Alucina com o mesmo desembaraço quer tenha razão ou não, e não fornece um grau de certeza fiável que um software pudesse aproveitar.

Em que é que o smart IF ajuda a contabilidade?

Torna fiáveis casos de uso como a geração de lançamentos, a conciliação, o IVA ou a imputação, e sobretudo a normalização dos dados contabilísticos, que desbloqueia novas missões de gestão e consultoria.

Referência: documentação TypeSafe AI, conceitos «System One» e «AI primer» (RLCD). docs.typesafe.ai →

← Todos os artigos Contacte-nos →