The confused job posting
The job posting had appeared in February on one of those boards where mid-size Italian companies look for technical people without being too sure what they are looking for. The position title was “Senior Software Engineer with Regulatory Background”, and there was already something strange about it, because in Italian a phrase like that does not mean anything precise. The body of the ad clarified little. It asked for at least five years of backend development experience, preferably Java or Python, knowledge of Kubernetes, experience with CI/CD pipelines. Up to here, a normal senior developer profile. Then the text changed register and started asking for in-depth knowledge of the GDPR, command of the AI Act regarding high-risk systems, the ability to draft DPIAs and risk assessments, experience with compliance frameworks such as ISO 27001 and SOC 2, the ability to interface with external auditors. The salary indicated was that of a senior developer at market rate, with a small unquantified premium for the regulatory competencies.
I read that posting ten times trying to understand who they were really looking for. A person like that, with that combination of skills, does not exist in Italy in meaningful numbers today, and when they do exist they cost twice what the company was offering. Whether the company knew this or not, hard to say. What is certain is that they had a real need, because they were about to deliver a system to a regulated client and did not have the right person in-house. They had senior developers who could not read a European Regulation, an in-house lawyer who could not read code, and an external compliance consultant who could speak with one of the two but not the other. The person they were looking for existed in their head as a translator between worlds that were not speaking to each other, but that person did not yet have a stable name as a trade.
The posting was reissued in March under a different title, “Compliance Engineer”, with no other changes to the body. Then it disappeared. I do not know whether the company found someone or gave up. What I do know is that postings like that, with minimal variants, I am seeing one or two a week passing on Italian boards, and many more on European ones. I am watching a craft looking for its name, one that will find it in the next two or three years because it has no alternative.
The technological objection
The objection I want to address right away, because it is the most serious and because it always comes from C-levels who are minding the costs, is the technological one. It goes like this: all the work you describe will be done by AI in three years. An agent will read the system, read the regulation, produce the mapping, update the documentation, flag the inconsistencies. There is no need to build a new professional figure — wait for the technology to mature. It is an objection with apparent plausibility, and it is widespread enough to deserve an answer. The answer is that AI will do ninety per cent of the mechanical work, and I am not making a cautious-cautious forecast here, I am describing what it already does in contexts where it is applied seriously. What remains, the ten per cent, does not correspond to the residual ten per cent we presume will vanish as models improve. It is the interpretive and political ten per cent, and it is precisely the part that requires a human being who understands at the same time the system’s architecture and the Regulation’s structure, and who knows how to choose how to align the two when the letter of the rule and the reality of the software come into tension — which happens far more often than regulators would care to admit.
Inverting the perspective, in fact, it is precisely AI that makes the compliance engineer figure economically viable. Without generative assistance, the volume of documentation required by the new European regime would be unmanageable for anyone who is not a multinational with a dedicated team of thirty. A software house of ten or fifteen cannot afford two full-time figures on this function, and indeed today it does not have them. But with well-configured AI assistance, one well-trained person can oversee the compliance of all the company’s projects with a quality that five years ago would have required a small team. The question to ask, then, is not whether AI will replace the compliance engineer — it is the exact opposite. Without AI, the compliance engineer would not exist as a role accessible to SMEs; it would only exist as a department in big companies. With AI, it becomes the synthesis figure that allows even mid-size organisations to operate in regulated markets without externalising their regulatory intelligence.
An institutional distance
Reconstructing how the conditions for this figure to emerge came about deserves some detail, because its genesis is typically Italian and European, and understanding the genesis helps understand why the trade has the shape it has. The starting point is an institutional distance between two academic and professional traditions that in Italy, more than elsewhere, have never seriously met. On one side computer science engineering, formed in engineering faculties, with historical attention to how software functions as a technical object. On the other side law, formed in law schools, with historical attention to norms understood as texts to be interpreted. The two traditions do not speak to each other — not because there are no people of good will trying to build bridges, but because curricula do not include the bridge as a structured object of study. The engineer leaves university knowing how to write code and design systems, but with an exposure to law that, at best, is limited to a one-semester course in IT law, often delivered by a teacher who studied software as a phenomenon and not as a practice. The lawyer leaves university knowing how to interpret norms, but with an exposure to software that, at best, is limited to a few conferences and a handful of popular manuals.
This distance was not a serious problem as long as software was assessed on functional, performance and commercial criteria. When software started to be assessed also on regulatory criteria, the problem exploded, because organisations found themselves having to certify to the regulator that their system met obligations that neither their developers nor their lawyers fully knew how to translate. The GDPR, applied from May 2018, was the first serious test. For years the response of Italian companies was either to outsource compliance to specialised consultants — who produced adequate documents but rarely went into the code — or to appoint an internal or fractional Data Protection Officer who spoke with the lawyer but little with engineering. It worked badly, but it worked enough, because the GDPR alone was not enough pressure to bring a new professional figure into being.
The pressure needed has arrived in the past three years with the accumulation of acts in the European digital regulatory package. AI Act, Cyber Resilience Act, revised Product Liability Directive, NIS2, Digital Operational Resilience Act for the financial sector, Data Act, European Accessibility Act. Each of these regulations, taken individually, would have been manageable with traditional methods. Taken together, and in the compressed times in which they have entered or are entering into force between 2024 and 2027, they have made the situation structurally different. Organisations producing software for the European market have found themselves with documentary, risk-assessment, security, traceability and accountability obligations that multiply and intersect in ways that demand an integrated view. The external consultant who produces one document at a time is not enough. The in-house lawyer who does not read code is not enough. The senior developer who explains the system to auditors twice a year is not enough, and neither is the combination of the three figures coordinating in periodic meetings — because coordination by periodic meetings is exactly the device that generates specification debt. You need someone who does only this, and does it every day, inside the organisation.
Three slices into one person
On a taxonomy-of-roles level, what is happening is that the compliance engineer is absorbing slices of work currently distributed across three distinct roles. First slice, the senior dev who today explains the system to auditors. It is a figure that exists in almost every organisation of a certain size, almost always a senior who has known the system for years and gets pulled out of development projects to do presentations to third parties. They do the work reluctantly because it is not what they were hired for, they do it with mediocre quality because they lack the documentary tools to do it well, and they fill their time with activities that drain value from the main role. Second slice, the architect who today translates regulatory requirements into design choices. This figure too is present almost everywhere, usually an architect who self-trained on regulation because someone had to, and who does it in the time left over from technical decisions, with the result that their design choices are excessively cautious where the regulations are ambiguous, and that they often over-regulate the system, generating useless operational friction. Third slice, the in-house lawyer or compliance consultant who today tries to read code without knowing how. This is the most frustrated figure of all, because they have formal responsibility but lack the technical tools to exercise it, and they end up asking devs things devs cannot translate into practice, generating a communicative loop that produces formally correct but substantively inert documents.
A typical day
The compliance engineer takes the three slices and brings them together in one person, with dedicated time and dedicated tools. A typical day, in a mid-size company that produces software for regulated clients, starts with a review of the week’s tickets to identify which code changes impact compliance. It continues with a working session on a specific pull request to discuss with the architectural reviewer the effects of a change on personal data flows. It carries on with a call to the in-house lawyer to clarify a contractual clause the client proposed that might come into tension with our technical security appendix. The afternoon goes to updating the DPIA of project X, because the third-party vendor changed hosting data centre and that modifies the cross-border flow mapping. It closes with a sprint planning meeting where the compliance engineer presents the documentation requirements for the next three tasks, so the team knows what to produce in addition to the code. None of this is legal in the strict sense, none of it is technical in the strict sense. All of it is techno-legal, and it is the hybrid nature of the work that justifies the figure.
Two degenerations
The risk of the role, which has to be named explicitly because it is the main risk, is that it can degenerate in two pathological directions, both already observable. The first degeneration is the compliance engineer as bureaucratic gate-keeper who blocks releases. It is the most visible and most damaging version, because it pits the compliance presence against delivery, and once that opposition stabilises the organisation loses both speed and compliance quality. The gate-keeper produces ever-longer checklists, demands ever-more articulated approvals, delays releases for reasons that look like formalisms to developers, and ends up being perceived as a cost to minimise rather than an investment to preserve. The second degeneration, opposite in symptoms but identical at the root, is the compliance engineer as policy decorator who signs documents without reading the code. You see this more in companies where the figure is introduced because a regulated client or an imminent audit requires it, and where the role is given to a person chosen for their willingness to bear documentary loads rather than for their actual ability to read the system. The decorator produces formally perfect documents, fills every required field, gets management to sign, and meanwhile the real system evolves in directions the document no longer describes. It is exactly the condition I called specification debt in the previous piece of this series, and that the compliance engineer should counter but instead contributes to generating if interpreted poorly.
Both degenerations have a common cause, which is the lack of structured training for the figure. When a trade has no academic reference path, everyone constructs it from their own provenance. The developer who becomes a compliance engineer brings the bias that compliance is a service function of the code, and tends to underestimate the legal consequences of technical choices. The lawyer who becomes a compliance engineer brings the opposite bias, that code is a service function of the norm, and tends to over-regulate with heavy technical and organisational consequences. A third trajectory, increasingly frequent, is that of the sysadmin who becomes a compliance engineer through natural affinity with documentary practices, and tends to build certification pipelines that live parallel to and never joined with the application development cycle. There is also a fourth trajectory, rarer but more promising, of those who arrive at the figure through mixed paths — for instance, those who have worked for years in product management on regulated products and have developed sensibility for both sides of the fracture. None of the first three trajectories produces, on its own, a compliance engineer up to the task. They produce half-figures that work in some companies and some contexts and fail elsewhere.
A real bicameral competence
What would be needed, and does not exist today, is a structured training path that starts from the assumption that the discipline is genuinely two-headed, engineering and legal at once, and that both halves require solidity, not superficiality. The compliance engineer’s software engineering is distinct from the simplified, generalist version found in popular courses, and demands real software engineering, with command of distributed architectures, application security, code lifecycle, DevOps practices, data modelling. The compliance engineer’s compliance, likewise, goes beyond the operational and checklist-driven version found in business school courses, and demands real European jurisprudence, with command of the Regulations, ability to read recitals, knowledge of Court of Justice case law, ability to anticipate the interpretive evolution of national authorities. A person who has all this is not formed in a six-month master’s, they are formed in some years of work guided by serious mentors, and serious mentors are still few.
The Italian university, from this point of view, is structurally late. Computer science engineering degrees, even the best ones, dedicate to regulatory compliance an amount of hours that is risible compared to the weight this discipline has assumed in the market. Law degrees, even the best ones, dedicate to software-as-regulated-object an amount of hours that is risible compared to software’s centrality in the economy. There are post-graduate master’s programs that try to fill the gap, and some are well done, but they are master’s — that is, six- or twelve-month complementary trainings that do not build the double competence from the ground up, they overlay it on a pre-existing competence. The result is that companies looking for compliance engineers do not find them trained by the university system and have to self-train them internally, with the time and cost that entails. It is a classic market distortion, where demand exists and supply has not yet consolidated, producing positions vacant for months and volatile salaries.
Big consultancies and the gap
The market segment that has already noticed the phenomenon, and is moving to occupy it before the others, is the big consultancies. It is the most visible and most ambivalent phenomenon, and it has to be assessed without moralism but with realism. Big consultancies have commercial muscle, presence with corporate clients, industrial processes for deploying professional figures, and budgets to produce internal training at speeds universities cannot sustain. They are building “compliance as a service” offerings that package the compliance engineer’s work in saleable bundles. The problem, and I say it without naming any specific actor because the problem is categorical and not individual, is that the version of the figure big consultancies are building is almost always the policy-decorator version. It is the most commercially scalable, easiest to sell, easiest to industrialise. The compliance engineer as a real techno-legal translator, the one who enters the code and modifies architectural choices, does not scale well in the consultancy model, because it requires continuity on the client that the project-based model typical of big consultancies does not easily provide.
The gap that big consultancies will not manage to cover, and that mid-size software houses could cover, is the compliance engineer internal to organisations producing software for regulated clients. Mid-size software houses, between ten and fifty people, are in a structurally better position to build this figure than either big consultancies or the regulated companies themselves. They have the technical proximity to the code that consultancies lack, the plurality of clients that regulated companies lack, the size that lets them sustain a dedicated person without externalising. What many Italian software houses do not have, and that is why they are not moving fast enough, is the awareness that the transformation is already underway and that whoever covers it first will gain a positional advantage hard to erode in the following five years.
On an operational level, building an internal compliance engineer means investing twenty-four to thirty-six months on a person who already has half the necessary skills. The typical candidate is a senior developer with curiosity for the regulatory dimension, an architect with sensibility to security and privacy, or a product manager with a certain taste for formalisation. The growth trajectory includes shadowing on real cases, systematic reading of European regulations in compared language versions, participation in audits with clients, drafting of DPIAs and risk assessments under supervision, building of documentary repositories, gradual exposure to in-house lawyers and external consultants to absorb vocabulary and legal practices by osmosis. It is a significant investment for a small software house, and it is exactly the kind of investment that produces a competitive asset hard to replicate.
Disclosure: a trajectory I inhabit
I have to be transparent, because on this topic I am describing a phenomenon I am part of, and the analysis would be dishonest if I did not declare it. The trajectory I am describing is the one I am living personally in my own company, and a non-secondary part of my work in the past two years has been building Oltrematica’s compliance engineer in-house, occupying that position directly while at the same time trying to formalise it for whoever will come after. I am not writing this piece as a neutral observer of someone else’s trend, I am writing it as someone who is inhabiting it from inside and who, after some years of practice, has the impression of having understood the shape the figure is taking and of having something to say about what works and what does not. I am not particularly happy or particularly proud of this trajectory. It is simply what the moment demands of those who want to keep making software for regulated clients without externalising their regulatory intelligence, and I have accepted it the way one accepts transitional duties, knowing that in ten years the figure will be obvious and that today it has to be built by groping.
Connection, and a forecast
There is a direct connection, and it is worth making explicit, between the figure I am describing and the two previous essays in this series. In the piece I called Cruft, Not Patina I argued that software does not know how to age, because the drift between code and the environment in which it runs erodes it faster than engineering culture can metabolise. In the piece that followed, The Specification Debt, I argued that the specification of software ages even worse than the code, because the continuous practice that would keep it alive is missing, and that the European regulatory framework is loading this ageing with legal consequences that did not exist before. The compliance engineer is the figure whose trade is precisely fighting specification debt day by day, keeping the specification aligned with the system as the system changes, and doing so with the bicameral competence that lets one fall neither into document formalism nor into code inertia. It is the person who, in an organisation that produces software, oversees the alignment between written promise and observed behaviour, knowing that under the new regime the coherence between the two planes is what the judge will assess if the day of assessment ever comes.
The piece closes with a forecast that is also a call to action for anyone reading from inside an organisation that makes software in Europe. In five years, around 2031, the compliance engineer will be obvious. There will be university degrees, there will be serious certifications, there will be professional bodies in some form, there will be regular columns in specialised media. What remains to understand is not whether it will happen, but only how fast. Organisations that are building it now, by hand and out of necessity, will have a structural advantage over those that wait for market maturity. The advantage plays out beyond the commercial plane — it is mostly cognitive, because whoever inhabits the role today is also defining the practices that will become standard, and whoever defines the practices defines them to suit their own way of working.
The compliance engineer figure is not a niche, it is the role redesigning how European software is produced under the new regulatory regime. It is happening slowly, in silence, in confused job postings looking for people who do not yet exist with titles that change month to month. When the postings find their stable name, and that will happen soon, the industry will split between those who invested in this figure in time and those who will have to import it at consolidated-market prices, three times as expensive. Anyone reading from inside a mid-size Italian software house probably has, in the company right now, the right person to train. It is a senior dev with their head sideways on regulations, or an architect who started reading the GDPR alone out of curiosity, or a sysadmin who took documentation to heart because no one else was looking after it, and in some cases a more hybrid figure arrived through mixed paths that fit none of the three classic trajectories. Recognising them and giving them an explicit mandate, investing time and structured training, is the managerial decision that will produce the most compounded value in the next five years. Not because the figure is fashionable. Because without it, in a few years, making software for regulated clients in Europe will become a craft that Italian software houses can no longer afford.
Key takeaways
The compliance engineer is the figure that consolidates into one person work currently scattered badly across three roles: the senior developer who explains the system to auditors, the architect who translates regulatory requirements into design choices, and the in-house lawyer who tries to read code without knowing how to read it.
AI will not replace the compliance engineer: it is making the role economically accessible to SMEs. Without generative assistance the documentary volume required by the new regime would be unmanageable below thirty dedicated people. With AI well configured, one well-trained person can cover the entire function.
Two pathological degenerations are already observable: the bureaucratic gate-keeper who blocks releases, and the policy decorator who signs documents without reading the code. Both share one root — lack of structured training for the role — and they generate specification debt rather than fight it.
Italian universities are structurally late: computer science engineering devotes negligible hours to law, law schools devote negligible hours to software as a regulated object. Master’s programs try to bridge the gap, but they overlay the second competence onto a pre-existing one rather than building both from the ground up.
The competitive window for mid-size software houses is two to three years. They have the technical proximity to the code that big consultancies lack, the plurality of clients that regulated companies lack, and a size that lets them sustain a dedicated person without externalising the function.
Questions & answers
Who is the «compliance engineer» and why are we only hearing about it now?
It is the figure that, day in and day out, holds together what the code does and what the technical and regulatory documentation declares. We are only hearing about it now because the pressure that makes it necessary is recent: the accumulation of European digital regulation between 2024 and 2027 (AI Act, CRA, revised PLD, NIS2, DORA, Data Act, EAA) has created a documentary volume that the occasional external consultant and the in-house lawyer unfamiliar with code can no longer handle alone. The figure existed in nuce in big companies; the regulatory package is promoting it to a structural role in mid-size organisations too.
Isn't this work AI will do in three years anyway?
No, and the observation is upside-down from how it is usually proposed. AI will do ninety per cent of the mechanical work — first-draft DPIAs, flow mapping, SBOM drafting, conformity checks against recitals — and that is already observable where it is applied seriously. The remaining ten per cent is not the residual ten per cent that vanishes as models improve, it is the interpretive and political ten per cent that requires a person who understands both the system’s architecture and the Regulation’s structure. AI is precisely what makes the figure economically viable: without it, the compliance engineer would only exist as a thirty-person team in multinationals; with it, one well-trained person in a software house of fifteen can cover the whole function.
How does the compliance engineer differ from a DPO, a security architect or an external compliance consultant?
The DPO has formal responsibilities specifically tied to data protection, defined by the GDPR, and is a legally identified figure. The security architect oversees the system’s security architecture. The external consultant produces adequate documents but rarely enters the code. The compliance engineer does not replace these three figures — it integrates them: the dedicated person who reads pull requests with the eye of the regulation, who fights the specification debt, who translates from the language of code to that of the Regulation and back, and who does it every day inside the organisation, not project by project.
What are the two pathological degenerations to avoid in building the role?
The first is the bureaucratic gate-keeper, who pits compliance oversight against delivery and produces ever-longer checklists, delaying releases with reasons that look like formalisms to developers. The second is the policy decorator, who signs formally perfect documents without reading the code while the real system evolves in directions the document no longer describes. Both share the same root — the lack of bicameral training — and they produce specification debt rather than fight it. The narrow path of the real compliance engineer runs between these two drifts.
Concretely, how does a mid-size Italian software house build this figure?
By investing twenty-four to thirty-six months in a person who already has half the necessary skills: typically a senior developer curious about the regulatory dimension, an architect with sensibility for security and privacy, or a product manager with a taste for formalisation. Growth trajectory: shadowing on real cases, systematic reading of European regulations across language versions, participation in audits with clients, drafting of DPIAs under supervision, building documentary repositories, gradual exposure to the in-house lawyer to absorb vocabulary by osmosis. It is a significant investment — and exactly the kind of investment that produces a competitive asset difficult to replicate.
Is there a connection between the compliance engineer and the two previous essays («Cruft, Not Patina», «The Specification Debt»)?
Yes, and that is why I wrote the three pieces in sequence. «Cruft, Not Patina» argues that software does not know how to age, because the drift between code and environment erodes it. «The Specification Debt» argues that the specification ages even worse than the code, because the continuous practice that would keep it alive is missing — and the European regulatory framework is loading that ageing with legal consequences that did not exist before. The compliance engineer is the figure whose trade is precisely fighting specification debt day by day, keeping the specification aligned with the system as the system changes, with the bicameral competence that lets you fall neither into document formalism nor into code inertia.
The author
