The HumanAI and OrgAI Calculator: a guided tour

,

Every screenshot is real, produced by running the instrument. The data in them is the illustrative example the calculator opens with, not any client’s data. The interface is in English.

What it is, in two sentences

The calculator is the digital instrument that accompanies the whitepaper “HumanAI and OrgAI: A Relational Framework for AI-Mediated Human and Organizational Capacity”. It turns the relationships defined there into an assessment record you complete for a concrete situation, one process, one team, one observation period, and which someone else can then verify, challenge and repeat.

A single HTML file. No installation, no account, no server, and no network request of any kind.

Interactive guide

The HumanAI and OrgAI calculator, layer by layer: the inputs, the evidence rule, modules 01–07, the ten-predicate detector and the export gate, with formulas and four computations you can run on the page.

What it looks like when you open it

The opening screen, with the action bar at the top, the results strip beneath it and the module navigation on the left
Figure 1. The opening screen. Action bar at the top, results strip beneath it, module navigation on the left.

It opens with a worked example, the illustrative case from the whitepaper, so you can see immediately how it behaves rather than facing an empty form. The “Reset example” button brings it back at any time.

Three zones, from top to bottom:

  • The action bar: the switch between working modes, resetting the example, importing a record, printing and copying the record.
  • The results strip: the four figures that summarise the assessment, the epistemic gap, propagation exposure, the organisational threshold and maturity. They stay visible whichever module is open.
  • The workspace: module navigation on the left, the active module on the right.

Navigation: eight modules and a diagnostic

The navigation column, where an orange dot marks a module with something outstanding
Figure 2. The navigation column. The orange dot marks a module that has something to resolve.

The modules are a sequence rather than a menu. Module 02 consumes the result of 01. Module 06 depends on 03. The classification worksheet, module 00, can stop everything else if the situation is not a HumanAI case.

The orange dots next to modules are a status signal: an incomplete record, conditions declared without evidence, a single dimension marked relevant, active diagnostic flags. You do not have to enter every module to find out where you still owe something.

At the bottom sit the canonical sources with the DOIs of the whitepaper and of the instrument, plus the note explaining the relationship between the current version and section 11.5 of the whitepaper.

Two working modes

The distinction between exploring and assessing is explicit, because mixing the two is the usual way results are produced that look like an assessment without being one.

Exploration mode, where results are marked illustrative and export is disabled
Figure 3. Exploration mode: results are marked illustrative, export is disabled.

In exploration mode you can move every value freely to see how the relationships behave. Evidence references are not required, and the record cannot be exported. Someone who only wants to understand the formula is not forced to complete a full record; in exchange, they cannot accidentally produce an artefact that looks like an assessment.

The action bar in exploration mode, with the copy button inactive
Figure 4. The action bar in exploration mode: the copy button is inactive.

Clear the checkbox and the instrument becomes demanding.

The record: what must be declared before any number

The whitepaper imposes a minimum reporting convention: any claim about HumanAI or OrgAI must identify the unit analysed, the task, the context, the AI configuration, the observation period, the validation method and the limit of responsibility. The instrument turns that into an operating condition.

The record header with missing fields highlighted and a counter showing 7 of 9 completed
Figure 5. Missing fields are highlighted. The counter shows 7 of 9 completed.
A banner stating how many fields are missing and that results remain provisional
Figure 6. The banner states how many fields are missing and that results remain provisional.

For as long as something is missing, export stays blocked and results are marked provisional. The modules keep calculating, so you can work, but you cannot produce a record that claims more than you know.

The completed record, with the copy button now active
Figure 7. The complete record: the copy button becomes active.

The record also carries an identifier of its own. If you keep it when reassessing the same unit six months later, the two records form a comparable series instead of being two unrelated assessments.

Module 00: classification, before measurement

The first question is not “how much” but “what are we assessing”. The ten questions of the membership test establish whether the situation is a HumanAI case and whether it meets the conditions for OrgAI.

The ten membership questions, each with a state and a field for the expected evidence
Figure 8. The ten questions. Each has a state and a field for the expected evidence.

Each question has three possible states, demonstrated, not satisfied and unknown, and a field in which you write the evidence, with a suggested example in place of the text (“catalogue, owners, provenance, validity”). The unknown state never counts as demonstrated.

One question alone stops the record: if you declare that the AI contribution is not material, the case is not HumanAI for that episode and the measurement modules no longer apply. Beneath the questions sits the list of cases the whitepaper excludes: an ignored suggestion, an automation with no AI component, several licences used independently.

Module 01: the gap between access and validation

This is where the central idea of the framework sits. You enter three numbers: how many tasks are in the declared set, for how many AI produced a usable answer, and for how many the accountable person could produce a verified justification.

Module 01 at 140 tasks, 126 with a usable answer and 95 with a verified justification
Figure 9. Module 01 at 140 tasks: 126 with a usable answer, 95 with a verified justification.

You enter counts, not estimated percentages. The reason is disciplinary: “about 90%” cannot be verified, “126 out of 140” can. And only counts allow the confidence of the result to be computed.

Compare the two screenshots. In the first, 0.22 over 140 tasks, with an interval of [0.13 – 0.31], gap demonstrated. In the second, a larger gap, 0.25, but over 12 tasks:

The same module at 12 tasks, where the interval crosses zero and the verdict becomes not demonstrated
Figure 10. The same module at 12 tasks: the interval crosses zero, the verdict becomes “not demonstrated”.

The interval is [-0.08 – 0.53], so it includes zero, and the verdict becomes “Not demonstrated”, not demonstrated at this task volume. A larger gap, poorly measured, supports less than a smaller one measured well. The instrument does not hide that difference behind the same two-decimal number.

The verdict is “not demonstrated”, not “no gap”. The distinction matters: absence of evidence is not evidence of absence, and the instrument’s wording respects that.

Below the result, a positive gap does not end with a number: the module displays the seven mitigation measures from the whitepaper as a selectable list, and what you tick there feeds the next module.

Module 02: what happens to an error in the flow

A gap in an isolated process is a local problem. In a process where the result is reused, it is amplified. The module models that amplification with two factors, the reuse rate and the criticality of the consequence, and computes two states: now, and after the controls you declare.

Current exposure and the target after controls, shown on the same scale
Figure 11. Current exposure and the target after controls, on the same scale.

The comparison is the argument, not the value on its own. The instrument shows the reduction as a percentage and flags separately the case in which the target would reduce exposure by cutting access rather than raising validation. Both lower the number, but they are entirely different decisions.

Module 03: the organisational architecture, with evidence

Six constitutive conditions: authorised knowledge, processes, roles and authority, governance, security, traceability. All six, otherwise the threshold is not demonstrated.

One criterion row, with the condition description, the evidence field, the evidence type and the state
Figure 12. One criterion: the condition description, the evidence field, the evidence type and the state.

Each criterion has three fields instead of a checkbox: the state, an evidence reference and its type. The rule that changes the nature of the instrument is simple: a criterion marked “demonstrated” without an evidence reference appears as declared, undocumented, and the field is highlighted. It does not count towards the threshold.

The counter becomes a pair: “5/6 declared · 4/6 documented”. The second number is the one that counts, and the difference between them shows exactly the distance between what an organisation believes about itself and what it can show.

Below the six, separated by a line, sits the seventh component, validated learning. It is part of the architecture but not of the minimum threshold: it conditions the M5 level only. The distinction belongs to the framework, and the instrument shows it rather than hiding it.

Module 04: the profile, not the score

The AI contribution is assessed across seven dimensions at once: quality, time, error, calibration, autonomy, learning and risk exposure. It is material if it exceeds the declared threshold on at least one relevant dimension.

The contribution profile, with a dotted no-AI baseline, a solid line for the assessed configuration and a grey threshold band
Figure 13. The profile. The dotted line is the baseline without AI, the solid line the assessed configuration, the grey band the threshold.

The chart shows what a single score would hide: in the illustrative example, quality and time improve, but autonomy and risk exposure worsen. The verdict is not compressed into a figure, it reads “material on 3 of 5 relevant dimensions”, with the difference and the direction for each.

Data is entered through one card per dimension:

The card for one dimension, where the threshold is declared before the results
Figure 14. The card for one dimension. The threshold is declared first, before the results.

The order of the fields is not accidental: the threshold appears before the two results, because the whitepaper requires it to be declared before the assessment, otherwise classification becomes opportunistic. If you change it after entering the results, the instrument records that in the record.

A dimension not marked relevant, collapsed to its title
Figure 15. A dimension not marked relevant collapses to its title: it stays visible, but empty.

A dimension that cannot be measured credibly is not filled with zero and not reported as “n/a”. It is left out of the decision, and the card collapses.

Module 05: synergy, with declared thresholds

Synergy is not assumed and is not a maturity level. It is demonstrated: the configuration must exceed every relevant comparator on the same task, and every declared risk threshold must be satisfied.

The four risk gates, each with a declared threshold and an observed value
Figure 16. The four risk gates. Each has a declared threshold and an observed value.

The gates are not checkboxes. Each requires a declared threshold and an observed value, and a gate without a declared threshold stays “undeclared” and blocks synergy just as a failed one does. You cannot demonstrate compliance with a threshold you never set.

The result names the comparator that binds the conclusion explicitly: “margin +0.06 over Human + AI (0.76)”. An anonymous margin would hide the decisive information: beating a person working alone and beating the best existing process are very different claims. The instrument also flags a weak comparator set.

Module 06: maturity, per domain

A level is assigned to a bounded domain and a process, not to an organisation. The whitepaper is explicit: the same company can be at M1 in one domain, M4 in another, and prohibit AI in a third.

Each domain with its name, process, progression states and the AI prohibited option
Figure 17. Each domain has a name, a process, progression states and an “AI prohibited” option.

You add as many domains as you need. Each gets its own progression states and can inherit the threshold from module 03 or override it locally. A domain in which AI is prohibited is recorded as such and appears without a level, not as M0, because a governance decision is not a maturity shortfall.

Above it, a compact matrix shows every domain at once. Below it, the M0 to M5 levels with the minimum evidence and the limit of each: for M3, “connectivity does not demonstrate governance”; for M4, “learning may remain manual”; for M5, “adaptation does not demonstrate synergy”.

Module 07: what the architecture produces

The threshold says the architecture exists. This module says what it produces: nine dimensions of organisational assessment, each with its value and its evidence.

The organisational profile, where dimensions not marked relevant stay dimmed
Figure 18. The organisational profile. Dimensions not marked relevant stay dimmed.

Two dimensions correlate with other modules, propagation with the exposure indicator from module 02, validation with V from module 01, and a large gap between them is itself a finding: it points to verification that is formal only.

The diagnostic

Across every module runs a detector that reads the configuration as a whole and looks for contradictions between what was declared in one place and what was measured in another.

The diagnostic state with no flags raised
Figure 19. The state with no flags. The wording avoids suggesting that an absence of signals means everything is fine.

Eight patterns from the whitepaper plus two internal consistency checks. When a flag is raised, it shows what triggered it, with the concrete values from the record, and the correction the framework prescribes. It can be annotated, and the annotation enters the record.

Flags do not change any result and do not add up into a risk indicator: that would reintroduce exactly the anti-pattern the instrument avoids in module 04.

What comes out of the instrument

The record

The JSON record, visible in the page and copyable to the clipboard
Figure 20. The record, visible in the page and copyable to the clipboard.

It contains the version of the instrument and of the whitepaper with their DOIs, every input, the computed values, the evidence references, the flags with their annotations, the record identifier, the generation timestamp and the limitation statement. It is copied to the clipboard rather than downloaded, because a page-initiated download does not work in every hosting context, and a button that does nothing is worse than no button.

Import

The import panel, which accepts a pasted record and migrates records from earlier versions
Figure 21. Import accepts a pasted record. Records from v1.0.0 and v1.1.0 are migrated.

A record can be reloaded. That makes periodic reassessment possible: you reopen the same record six months later, change the period, recount, and compare. Records from earlier versions are migrated, with an explicit note of what could not be recovered.

The printed record

The first page of the printed record, showing the header with the minimum reporting convention
Figure 22. The first page of the printed record: the header with the minimum reporting convention.

Printing produces the document an auditor or a client receives: a header with the nine fields of the record, the identifier, the state and the date, then each module with its values rendered as text rather than as a form. Roughly 17 pages for a complete record. The JSON record is not printed, so the document is not duplicated.

Properties

PropertyState
InstallationNone. One HTML file opened in any modern browser
Network requestsNone. Fonts are embedded; it works on an isolated network
Browser persistenceNone. No localStorage, no cookies
Account, database, analyticsNone exist
Security policyRestrictive CSP in the self-hosted variant, with connect-src “none”
ThemesLight, dark and the system theme
Verification29 automated tests that extract the logic from the delivered file

The last two deserve a look. The instrument follows the system theme with no setting:

The same module rendered in the dark theme
Figure 23. The same module in the dark theme.

And the tests do not hold a copy of the formulas: they extract them from the shipped file, between two markers in the code, so they cannot drift from it. A passing run is a statement about the file in your hand, not about a laboratory version.

Limits

  • Results are interpretive. They do not constitute empirical validation, certification, legal advice or a compliance determination.
  • The instrument verifies nothing: every value remains a claim by the assessor until it is tied to the evidence it points to.
  • The propagation indicator is conceptual; without local calibration it does not estimate real probabilities.
  • Thresholds are declared by the user, according to domain and risk. The instrument does not calibrate them.
  • The “unknown” state never counts as demonstrated, at any step.
  • The instrument cannot be the sole basis of a consequential decision.

The last two remain permanently visible in the interface, not only in the documentation.

Citation and licence

The framework: Angheluș, A. (2026). HumanAI and OrgAI: A Relational Framework for AI-Mediated Human and Organizational Capacity, v1.5. Zenodo. DOI 10.5281/zenodo.22295278

The instrument: Angheluș, A. (2026). HumanAI and OrgAI Framework Calculator, v1.2.0. Zenodo. DOI 10.5281/zenodo.22884721

When you rely on the definitions or on the interpretation of the framework, cite both. The code is licensed under MIT, © 2026 S.C. PRODEFENCE S.R.L.; the conceptual framework and the interpretive text remain under CC BY-ND 4.0, as published in the whitepaper. The PRODEFENCE mark is licensed by neither.

Further reading

The version 1.2.0 announcement, with what changed since 1.0.0, is in the HumanAI and OrgAI Framework Calculator, version 1.2.0. The conceptual framework behind it, with the definitions, the constitutive threshold and the threat model, is explained in HumanAI and OrgAI: what capacity has the organisation built.

Frequently asked questions

What does the guided tour of the calculator cover?

It walks screen by screen through the eight modules of the HumanAI and OrgAI Framework Calculator, plus the diagnostic, with 23 real screenshots: what you see, what you enter and what you get at each step.

What is the difference between exploration mode and assessment mode?

In exploration mode you can move values freely to see how the relationships behave; evidence references are not required, results are marked illustrative and export is disabled. In assessment mode the record becomes mandatory, and export unlocks only when it is complete.

Why are counts entered instead of percentages?

Because “about 90 per cent” cannot be verified, while “126 out of 140” can. Only counts allow the confidence interval that shows whether the gap is demonstrated at the assessed task volume.

What happens if a condition is marked demonstrated without evidence?

It appears as declared, undocumented, the field is highlighted, and it does not count towards the constitutive threshold. The counter shows two numbers, declared and documented, and the difference between them shows the distance between what an organisation believes about itself and what it can show.

What does the instrument produce at the end?

Three things from the same record: the on-screen assessment, a printed record of about 17 pages with the minimum reporting convention in its header, and a JSON record containing the inputs, computed values, evidence references and the limitation statement.

Can an assessment be repeated six months later?

Yes. The JSON record is copied, archived and re-imported, including from earlier versions. If you keep the record identifier, the two assessments form a comparable series instead of two unrelated ones.

Financial market infrastructure: 4.83 out of 5 on backups. The best DNSC score and what still needs proving

Romania’s financial market infrastructure scored 4.83 out of 5 on CyFun® control PR.DS-11.1, the strongest result in the entire DNSC series. The control requires business-critical data to be backed up and stored on a system separate from the one holding the original data, precisely so that it survives loss, system failure and ransomware.

The score is no surprise. This is the only sector in the series where separate backups were already a regulatory requirement rather than a good practice. The useful question is not how the sector reached 4.83, but what remains to be demonstrated beyond this control.

What was measured

The data comes from the PNRR 184 project “Creating new cybersecurity competencies for society and the economy”, under which 1,599 public and private beneficiaries self-assessed on the SecureRO platform using the CyberFundamentals (CyFun®) framework of the Centre for Cybersecurity Belgium. DNSC’s conclusion: the high level indicates a good capacity to protect critical data through secure, separate backups, supporting operational resilience and rapid recovery.

The difference between holding copies and being able to return

Control PR.DS-11.1 verifies that copies exist and are separated. It does not verify restoration. That distinction decides, in real incidents, between an outage of hours and one of days. The questions a 4.83 leaves open:

  • when the last full restoration was performed on a separate system, timed and recorded;
  • how long the service itself takes to return, not how long files take to copy, including rebuilding dependencies and verifying data integrity;
  • whether a copy exists that is unreachable from the network and immutable, surviving an attacker holding administrative rights;
  • whether the encryption keys for the copies are held somewhere other than the protected system;
  • whether the person able to run the restoration is available outside working hours, and whether the procedure works without them;
  • whether suppliers hosting parts of the service keep verified copies of their own, with a contractual duty to prove it.

A documented restoration exercise, run at least annually, turns a declared score into evidence. Without it, the figure remains an intention.

Which legal regime actually applies

Here the financial sector has a particularity the others do not. The NIS2 Directive provides that where a sector-specific EU act imposes at least equivalent requirements, that act applies instead of the general regime. For financial entities, that act is Regulation (EU) 2022/2554 on digital operational resilience, applicable since January 2025, covering ICT risk management, incident reporting, resilience testing and oversight of critical third-party providers.

The practical consequence is that an entity in the financial market infrastructure should not assume automatically that the GEO no. 155/2024 regime applies to it in full, nor assume the opposite. The perimeter is established by entity type and by the activities carried out, and groups with mixed activities may sit under both regimes simultaneously for different components. Establishing the perimeter correctly is the first deliverable, not a formality.

Where the general regime does apply, the administrative obligations are the familiar ones: notification for registration within 30 days under art. 18 para. (2), risk level assessment using ENIRE@RO, the annual maturity self-assessment under art. 12 para. (4), and the incident reporting deadlines of art. 15 para. (7): 24 hours, 72 hours, one month.

Where the advantage is lost

Organisations with high technical maturity rarely fail on the technical side. They fail on demonstration: the policy approved by the management body is missing or outdated, the responsibility matrix no longer matches the org chart, the incident register contains only the large events, and the evidence of accredited management training required by art. 14 para. (2) does not exist.

Through Order no. 3 of 27 November 2025, the DNSC director approved the rules on supervising, verifying and enforcing compliance with the ordinance, together with the risk-based prioritisation methodology. Verification starts from documents. An impeccable backup system, without the documentation describing it and the record of its tests, presents badly in exactly the place where it should be strongest.

The exercise that validates the score

A serious restoration test is not announced a month in advance and is not run on a conveniently chosen file. Pick a real service, assume the original system no longer exists, and time the whole path: identifying the correct copy, obtaining the keys, rebuilding the environment, verifying data integrity, restarting the service and confirming that the data is what was expected, not merely present.

The result is compared against the declared recovery time and maximum data loss objectives. The gap between the two is the only honest measure of resilience, and recording it, with date, participants, problems encountered and remediation actions, is precisely the evidence an inspection asks for.

A second, shorter exercise concerns third parties: ask a supplier hosting part of the service for evidence of its last restoration test. The answer, or the absence of one, says more about real resilience than any questionnaire completed at contract signature.

Next steps

The first step is delimitation: what applies to the entity and at what level. The CysNis platform walks through the qualifying criteria with references to the legal text.

For evidence-based verification of the measures and the documentation presented at an inspection, including restoration scenarios, the next step is a NIS2 compliance analysis with a remediation plan, carried out by DNSC-attested NIS auditors on the ProDefence team. Entities that prefer not to load their internal team with compliance work can cover the role through an outsourced NIS2 officer. The full range of services is in the cybersecurity services register.

A 4.83 out of 5 is a real advantage. It turns into demonstrable compliance only when it comes with proof: recorded tests, approved policies, assigned roles and a clear delimitation of the applicable regime.

Data source: DNSC, “Cyber maturity score for Romania’s financial market infrastructure, CyFun® control PR.DS-11.1”, 24 August 2026.

Energy: 2.15 out of 5 on the critical supplier register. Supply chain risk under NIS2

Romanian energy sector entities scored 2.15 out of 5 on CyFun® control GV.SC-07.2, which requires a documented list of all critical suppliers, vendors and partners who could be involved in a major incident, established, kept up to date and available both online and offline. DNSC rated the result as low.

Two words in the control text explain both the low score and why it matters: “updated” and “offline”. The first is missed for lack of process. The second is missed because nobody pictures the day the systems do not come back up.

The figure in context

The measurement comes from the PNRR 184 project “Creating new cybersecurity competencies for society and the economy”, in which 1,599 public and private beneficiaries assessed their own maturity on the SecureRO platform using the CyberFundamentals (CyFun®) framework of the Centre for Cybersecurity Belgium. DNSC’s conclusion for energy: records and updates concerning critical suppliers and partners need strengthening, to support a rapid and coordinated response to major incidents.

The list is not a supplier table

Every energy company has a supplier list, in its procurement system. The control asks for something else: a record of those third parties whose unavailability or compromise would affect the service, with the information needed to reach them and work with them mid-incident. The difference shows up in the columns:

  • what service or equipment they supply and what stops without it;
  • the technical contact, not the commercial one, with a direct number and a named backup;
  • actual availability hours and the contractual response time;
  • the type of access they hold in your infrastructure, remote, permanent, through a dedicated account or a shared one;
  • their own notification obligations in case of an incident on their side, and the deadline for informing you;
  • the alternative, if one exists, and the time needed to switch to it.

In an energy company, the list must also cover industrial control system integrators, equipment manufacturers with remote maintenance, communications providers carrying telemetry and the data centre operators hosting supporting systems. These are, as a rule, the ones missing from existing records.

Why “offline” is not a formality

The scenario in which the list is most needed is exactly the scenario in which it cannot be reached: the network has been isolated as a precaution, the directory service is compromised, e-mail is down, work phones are locked because authentication runs through the affected system. A record living only on the intranet or in a cloud service tied to company accounts becomes unusable in precisely the hour it mattered.

The offline version means a printed copy or separate media, kept in known locations, under confidentiality controls, the list contains information that, in the wrong hands, describes the organisation’s weak points exactly. The control says explicitly that the record is kept “with due regard to confidentiality and security”.

What the law requires beyond the control

Art. 11 para. (1) of GEO no. 155/2024, approved by Law no. 124/2025, requires essential and important entities to take proportionate and appropriate measures to identify, assess and manage risks affecting the networks and information systems they use, and to reduce the effects of incidents on the recipients of their services and on other services. That final phrase covers propagation through the supply chain directly.

In energy, this effect has a dimension other sectors lack: interdependence. An incident at a supplier shared by several operators does not produce nine separate problems but one, simultaneous, with immediate public pressure. The ordinance’s preamble cites exactly such a case from another sector, the first quarter of 2024, when 26 hospitals were affected through the same managed service provider.

To this are added the reporting deadlines of art. 15 para. (7): early warning within 24 hours, incident notification within 72 hours, final report within one month. When the cause sits with a third party, the first hours go into finding out whose and what, or they do not, if the record exists.

A simple test

Pick a critical supplier and ask, without warning, for three pieces of information: the name of the technical contact, the contractual response time and the type of access they hold in your infrastructure. If the answer takes more than an hour and involves opening the procurement system, control GV.SC-07.2 is not met, however good the self-assessment looks.

Second test: ask who maintains the list and when it was last reviewed. A record without a designated owner and a review interval is a document, not a control.

Next steps

The volume of measures depends on the risk level produced by the ENIRE@RO assessment and validated by DNSC. Before anything else, scope is established: the CysNis platform walks through the criteria with references to the legal text.

For the critical supplier record, the contractual security clauses and the documentation required at an inspection, the next step is a NIS2 compliance analysis with a remediation plan, carried out by DNSC-attested NIS auditors on the ProDefence team. Operators without a dedicated internal role can cover it through an outsourced NIS2 officer, including the annual self-assessment required by art. 12 para. (4). The full range of services is in the cybersecurity services register.

There is one more effect operators underestimate: the critical supplier list is also a negotiating instrument. Once you know exactly what stops without each third party and how quickly, the conversation about security clauses, notification deadlines and audit rights is held with arguments rather than boilerplate. Suppliers who refuse those clauses identify themselves, and that, in itself, is risk information.

Data source: DNSC, “Cyber maturity score for Romania’s energy sector, CyFun® control GV.SC-07.2”, 25 August 2026.

HumanAI and OrgAI: what capacity has the organisation built

,

A group of employees using the same AI model does not constitute organizational capacity. The difference between the two is not one of scale but of architecture, and the HumanAI / OrgAI framework makes it visible, measurable and auditable.

Alexandru Angheluș · September 2026 · Based on “HumanAI and OrgAI: A Relational Framework for AI-Mediated Human and Organizational Capacity”, version 1.5, DOI 10.5281/zenodo.22295278, licensed CC BY-ND 4.0.

The question a licence count cannot answer

AI adoption is usually reported through product names, licence counts or automation volumes. Those figures show that the technology is available. They do not show which capacity has been created, where knowledge resides, how results are validated, or who holds authority.

The same interface may support a competent professional, induce uncalibrated dependence, or propagate an error throughout an organization. The central confusion is between individual AI use and organizational capacity. Without authorized sources, roles, validation, traceability, security and controlled memory, the result is aggregated use rather than governed capacity.

For a security or compliance officer the consequence is immediate and practical: in a supervisory enquiry, an audit or a risk assessment, a licence count is not an answer. It does not say which sources produced the conclusion, who verified it, who is accountable for it, or how it can be reconstructed.

Two constructs, two units of analysis

HumanAI

HumanAI denotes a situated person–AI–task–context configuration in which an AI system materially changes a person’s performance, judgment, learning or vulnerability, while the human role and decision authority remain identifiable.

The contribution may be positive, neutral or negative. Overreliance, error or skill erosion do not remove a case from the category, they describe its outcome profile. The configuration is episodic when it concerns a bounded task, and becomes stable when repeated use changes the person’s practice, trust, competence, autonomy or validation behaviour.

OrgAI

OrgAI denotes the organizational socio-technical configuration in which HumanAI episodes, AI systems, authorized institutional knowledge, roles, workflows, validation, traceability, security and control jointly mobilize a distributed capacity that cannot be attributed to a single user or model.

OrgAI is not a product, a model, an agent or a document repository. It is a property of the organizational configuration.

Reading rule: HumanAI and OrgAI describe configurations, not outcomes. A configuration may produce good, poor or unsafe results. Category membership and outcome quality are separate judgments.

Excluded cases

  1. An ignored AI suggestion with no material effect does not constitute HumanAI in that episode.

  2. A deterministic automation without an AI component is not included merely because it is complex.

  3. Multiple independently used AI licences do not constitute OrgAI.

  4. A chatbot connected to unverified documents does not demonstrate authorized organizational knowledge.

  5. A system-only decision without identifiable authority and accountability does not satisfy the governed framework.

The membership test

Classification is not established by declaration but through seven questions applied to a bounded configuration.

Test HumanAI OrgAI
Identifiable unit person, system, task and context organizational process, actors, systems and knowledge
AI contribution materially changes execution or judgment is integrated into institutional capacity
Authority human role and decision can be attributed roles, approvals and escalations are defined
Knowledge relevant sources can be delimited sources are authorized, versioned and owned
Validation the person can verify in proportion to risk validation is independent and institutionalized
Traceability the episode can be reconstructed the workflow and decision can be audited
Learning effects on the person can be tracked validated feedback updates memory in a controlled manner

Table 1. Membership and boundary criteria.

The constitutive threshold: why OrgAI is not the sum of episodes

The relationship between the two levels is one of conditional integration. Individual episodes provide local contributions. Organizational architecture selects, authorizes, coordinates, validates and retains only those contributions that can become part of institutional capacity.

OrgAI ≠ Σ HumanAIᵢ

Iorg = 1[Korg ∧ P ∧ R ∧ G ∧ S ∧ T]

The Iorg indicator expresses the minimum conceptual threshold: Korg is authorized institutional knowledge, P are processes and control points, R are roles and accountability, G is governance with validation, contestability and audit, S is security and data protection, and T is configuration and decision traceability.

If any of these components is missing, the configuration may represent connected or aggregated AI use, but it does not demonstrate governed OrgAI. Controlled learning is required for the cumulative form, not for the minimum threshold.

The transformation mechanism

  1. An actor performs a task within a delimited HumanAI configuration.

  2. The output is accompanied by sources, configuration, interventions and confidence level.

  3. A competent role validates or rejects the contribution in proportion to risk.

  4. The decision is attributed and integrated into a controlled organizational process.

  5. Accepted conclusions may update memory only through a separate adjudication workflow.

  6. Outcomes and errors are monitored, and access or rules can be withdrawn or corrected.

Epistemic decoupling: the risk that appears in no control catalogue

Epistemic decoupling is the gap between the range of claims, interpretations or options that AI makes accessible and the demonstrated capacity of the accountable actor to validate them.

Δepi(T; X, t) = A(T; X, t) − V(T; X, t)

Across a declared task set T, A is the proportion of tasks for which the system provides a usable response, and V is the proportion for which the accountable actor can produce a verified justification. The difference is calculated within the same domain and ranges from −1 to 1. A high positive value shows that access has outpaced validation.

The distinction matters for governance because it separates three questions that practice routinely conflates: what the system can generate or retrieve, what the competent actor can validate, and who is authorized to decide or execute. Access to a claim does not automatically produce justified knowledge, and technical validation does not automatically confer decision authority.

Observable signals

  1. Responses are accepted faster than their sources can be checked.

  2. Citations, explanations or calculations cannot be reproduced independently.

  3. The same output is reused across processes without reassessing context.

  4. Reported confidence rises while error-detection rates decline.

  5. Organizational memory is updated with unadjudicated outputs.

  6. Authority is formally assigned to a person, but practical constraints make contestation impossible.

Mitigation measures

  • Limit the domain and state the unknowns.

  • Cite and verify primary sources.

  • Require independent validation for high-impact outputs.

  • Separate generation from approval and execution.

  • Test trust calibration and error detection.

  • Control reuse and memory updates.

  • Preserve the right to contest, to stop, and to return to the unassisted process.

Propagation: how a local error becomes systemic risk

Ωprop = max(0, Δepi) × ρ × κ

ρ is the rate at which an output is reused or diffused, and κ is consequence criticality. Without local calibration the formula does not estimate real-world probabilities. Its role is different: it makes visible why a small error, reused frequently in a critical process, may become a major organizational risk, and why reducing decoupling has a multiplicative rather than linear effect.

Five use scenarios

7.1. Analysis and research

An analyst uses AI to identify themes, synthesize documents and formulate hypotheses. The configuration is HumanAI when the intervention materially changes the scope or speed of analysis. The corpus must be bounded, citations verified, inferences labelled as such, and the analyst’s decision retained.

The configuration becomes part of OrgAI only when sources, rights, methodology, validation and reuse are integrated into an institutional process. The dominant risk is that a plausible but unverified synthesis becomes organizational fact.

7.2. Creation, communication and marketing

AI can expand the space of concepts, audiences and creative variants. Each creator–model–brief relationship is HumanAI. OrgAI requires authorized data, asset rights, approval criteria, versions, performance evaluation and controlled feedback. Abundance does not demonstrate relevance and may produce narrative convergence or homogenized expression.

7.3. Cybersecurity

A security operations analyst uses AI to correlate alerts, formulate hypotheses and propose investigative steps. HumanAI describes the analyst–model–telemetry episode. OrgAI emerges when identities, data classification, chain of custody, sources, approval roles, logging and response procedures are integrated.

Automatic execution of proposed commands, contamination of memory with unverified indicators, or exposure of investigative data are cases in which speed has overtaken control. Destructive operations require explicit confirmation, separation of duties and rollback capability.

7.4. Compliance and evidence evaluation

AI can map requirements to policies, controls and evidence. At HumanAI level the assessor receives suggestions and syntheses. At OrgAI level the organization manages control owners, periods, versions, exceptions, approvals and evidence lineage. The existence of a document does not establish control operation, and an automated score does not demonstrate compliance.

7.5. Organizational memory and strategic decision-making

An organization connects AI to policies, projects, lessons learned and prior decisions. Retrieval is useful only if sources have status, version, owner and scope. The cumulative form emerges when validated conclusions update memory without self-confirmation and obsolete information can be withdrawn. Strategic decisions remain attributable to authorized roles.

Scenario HumanAI unit Threshold for OrgAI Dominant risk
Analysis analyst, model, corpus, question institutional sources and validation unverified citations and conclusions
Creation creator, model, brief, audience rights, approval, controlled feedback convergence and unauthorized use
Security analyst, telemetry, hypothesis chain of custody, roles, audit incorrect execution and contamination
Compliance assessor, requirement, evidence owners, periods, adjudication apparent compliance
Memory user, question, internal sources validity and validated learning propagation of obsolete information

Table 2. Scenario summary.

Demonstrative case study: assessing an incident

Status: this case is hypothetical and explanatory. The values are illustrative, not empirical findings, and do not represent the performance of any real product or organization.

An organization must assess a potential cyber incident. Inputs include alerts, logs, internal procedures, threat intelligence and prior reports. A wrong conclusion may interrupt services, destroy evidence, or cause a real incident to be missed.

The HumanAI episode

The analyst asks the model for a timeline, hypotheses and validation steps. AI reduces triage time and expands the hypothesis space, so its contribution is material. The analyst verifies events in primary sources, marks inferred claims, and retains authority over classification. The configuration remains HumanAI even when some suggestions are rejected.

Aggregated use that is not OrgAI

Several analysts use the same model independently and copy its answers into tickets. There is no source catalogue, configuration version, adjudication role or rule for updating memory. This is aggregated AI use. Activity volume does not compensate for missing architecture.

The governed OrgAI configuration

  • Sources are classified, owned and filtered before retrieval according to analyst identity.

  • Retrieved content is treated as untrusted data and cannot introduce executable instructions.

  • The model produces hypotheses linked to primary events and states missing data.

  • A separate validator adjudicates critical claims, while the decision-maker approves the operational response.

  • Commands are denied by default and require confirmation, logging and target-domain validation.

  • Only adjudicated conclusions can update case memory; rejected indicators are withdrawn and remain auditable.

Illustrative decoupling calculation

Initial: A = 0.92; V = 0.68; Δepi = 0.24

After controls: A = 0.92; V = 0.88; Δepi = 0.04

Access has not been reduced, but validation capacity has increased through primary sources, adjudication and traceability. If the reuse rate ρ is 0.80 and criticality κ is 0.90, the conceptual propagation indicator falls from 0.173 to 0.029. The values only explain the relationship among variables.

The practical observation for a security officer is that the fix was not to restrict access to the tool, the usual reflex, but to raise validation capacity. Restricting access would have lowered A, and with it the utility, without addressing the underlying problem.

Maturity: six states, none of them mandatory

The maturity model describes observable states of integration, not an obligation to reach the highest level. For some tasks, a managed HumanAI configuration is more appropriate than the cumulative form. A level is assigned to a bounded domain and process, not to an organization in the abstract.

Level Description Minimum evidence Boundary
M0 Exploratory occasional use without stable practice inventory of uses or experiment does not demonstrate stable HumanAI
M1 Episodic HumanAI AI materially changes bounded tasks artifacts and task comparator the effect is not institutionalized
M2 Managed HumanAI practice is repeatable and governed locally guidance, measurement, validation, owner more users do not imply OrgAI
M3 Connected OrgAI models access organizational sources and workflows source catalogue, identities, integration connectivity does not demonstrate governance
M4 Governed OrgAI the constitutive threshold is satisfied roles, validation, audit, security, contestability learning may remain manual
M5 Cumulative OrgAI adjudicated feedback updates controlled memory staging, approvals, history, withdrawal, testing adaptation does not demonstrate synergy

Table 3. Maturity levels.

The status of synergy: “Synergistic OrgAI” is an outcome label, not an M6 level. It applies only to a configuration and task for which comparators and risk thresholds have been evaluated explicitly.

An organization may operate at M1 in one domain, at M4 in another, and prohibit AI use in a third. Applying a single level to a whole organization is itself an assessment error.

Governance: roles, incompatible shortcuts and threats

Governance is not a separate chapter of the framework but the element that constitutes the category. Removing authority, validation or traceability does not weaken an OrgAI configuration, it moves it out of the category.

Role Primary responsibility Incompatible shortcut
Process owner defines purpose, scope and acceptance criteria delegating purpose to the vendor or model
Knowledge owner authorizes sources, validity and withdrawal treating every accessible document as authoritative
User or operator performs the task and records interventions copying output without review
Validator tests claims against criteria and evidence validating one’s own high-impact output without controls
Decision-maker accepts consequences and authorizes action assigning responsibility to AI
Security and privacy controls access, isolation, retention and incidents relying solely on vendor terms
Audit or oversight tests reconstruction, exceptions and effectiveness treating policy existence as operating evidence

Table 4. Roles and separation of duties.

Threat Mechanism Minimum controls
Prompt injection retrieved content manipulates model behaviour separate instructions from data, sanitize, constrain tools, test adversarially
Unauthorized disclosure prompts, context or logs expose protected data classification, minimization, access control, retention limits, redaction
Privilege confusion the model acts with broader rights than the user identity propagation, least privilege, target checks, deny by default
Hallucinated authority plausible output is treated as an approved decision source verification, status labels, validator and decision-maker
Memory contamination unverified feedback becomes institutional truth staging, adjudication, provenance, rollback and withdrawal
Automation bias human review becomes formal rather than effective error-detection tests, time allocation, independent evidence, contestability
Common-mode failure one defect propagates across downstream uses diverse sources, dependency mapping, monitoring and kill switch

Table 5. Threat model and minimum controls.

What the framework does not demonstrate

Much of the framework’s practical value lies in what it refuses to confirm.

Anti-pattern Why it is incorrect Correction
AI as authority output is treated as the decision retain a decision-maker, validation and contestability
Nominal human in the loop a person approves without time, competence or evidence access measure actual detection and intervention capacity
OrgAI by licence count account numbers are confused with integration evaluate sources, roles, workflows and controls
Memory without adjudication all feedback becomes institutional truth separate raw feedback from approved updates
Single score trade-offs and risks are hidden report dimensional profiles and thresholds
Convenient comparator gain is measured against a weak baseline include the best realistically available process
Irreversible automation a suggestion triggers action without control deny by default, confirm, log and support rollback
Compliance label the concept is treated as legal or audit evidence demonstrate obligations and control effectiveness separately

Table 6. Anti-patterns and corrections.

Six explicit clarifications follow: HumanAI does not mean that a person becomes AI or that a system acquires human status; HumanAI is not synonymous with success; OrgAI is not the name of a model or a commercial package; access to an internal corpus does not demonstrate provenance, validation or authority; automation does not transfer accountability to AI; and using the term OrgAI does not make an organization mature, safe or compliant.

The regulatory boundary

The framework supports analysis and control design but does not establish legal compliance. Systems with material effects on rights, safety, employment, finance, health, security or public services require domain-specific legal assessment, data protection analysis, competent human oversight, contestability, separation of duties and evidence preservation. The HumanAI or OrgAI labels do not replace applicable obligations.

From framework to implementation

Stage Activity Exit criterion
1. Delimitation select process, tasks and consequences approved scope, owner and exclusions
2. Baseline measure the process without the new configuration comparator, thresholds and task set
3. Controlled HumanAI pilot with users, rules and validation documented material contribution and risk profile
4. Knowledge catalogue and authorize sources owners, validity, access and withdrawal
5. OrgAI threshold integrate roles, workflow, audit and security Iorg test satisfied with evidence
6. Operational pilot test normal, boundary, adversarial and unavailable states approved acceptance criteria and residual risk
7. Controlled learning introduce adjudicated feedback and withdrawal updatable, auditable, reversible memory
8. Monitoring track profiles, changes and incidents periodic review and stop conditions

Table 7. Implementation pathway.

Stop conditions

Implementation must stop or return to the previous state when data exposure, loss of decision attribution, degradation in error detection, unauthorized access, memory contamination, inability to reproduce critical results, or an unvalidated configuration change occurs.

The computational companion

The HumanAI and OrgAI Framework Calculator is the separately versioned digital companion to the framework. It operationalizes six relationships defined in the whitepaper: epistemic decoupling, propagation exposure, the constitutive OrgAI threshold, material contribution, synergy and maturity classification.

It should be used only after defining the unit of analysis, task, context, observation period, comparator, materiality threshold and evidence standard. Every organizational condition must be supported by evidence, and an unknown state never counts as demonstrated. The local release calculates in the browser and can export a JSON assessment for reproducibility and audit. Exported values remain user-entered claims until linked to evidence; results are not empirical validation, certification, legal advice or a compliance determination.

Software citation: version 1.2.0, DOI 10.5281/zenodo.22884721.

Interactive guide

The HumanAI and OrgAI calculator, layer by layer: the inputs, the evidence rule, modules 01–07, the ten-predicate detector and the export gate, with formulas and four computations you can run on the page.

Interactive guide

The HumanAI and OrgAI framework, layer by layer: the foundations, the individual configuration, the membership test, the Iorg threshold, epistemic decoupling, maturity M0–M5 and governance, with four computations you can run directly on the page.

The decisive question

The framework’s value does not depend on who first used the HumanAI notation, nor on the absolute absence of a similar expression for OrgAI. It depends on definitional clarity, on the separation of constructs from outcomes, on the relational model, and on the ability to make accountability, validation, authority and risk visible.

In practice, the decisive question is not whether an organization uses AI. It is whether the organization can demonstrate which capacity it has created, in which domain, from which sources, through which roles, with what validation, and within which limits. HumanAI makes the person’s configuration visible. OrgAI makes visible the institutional architecture that can turn it into controlled collective capacity.

For security and compliance professionals the operational consequence is that assessment applies to a bounded configuration rather than to a model, and that validation, not access, remains the central problem between the availability of technology and real capacity.

Source

Angheluș, A. (2026). HumanAI and OrgAI: A Relational Framework for AI-Mediated Human and Organizational Capacity. Version 1.5, 4 September 2026. DOI: 10.5281/zenodo.22295278. Licensed under Creative Commons Attribution-NoDerivatives 4.0 International.

Further reading

The instrument that operationalises the relationships described here is presented in the HumanAI and OrgAI Framework Calculator, version 1.2.0.

For governing the AI tools an organisation actually uses, CysAI provides a catalogue of AI agents with risk profiles and tracking of artificial intelligence regulation.

Frequently asked questions

What is HumanAI?

HumanAI, also written HumanAI, denotes a situated person, AI system, task and context configuration in which the system materially changes a person’s performance, judgement, learning or vulnerability, while the human role and decision authority remain identifiable.

What is OrgAI?

OrgAI denotes the organisational socio-technical configuration in which HumanAI episodes, AI systems, authorised institutional knowledge, roles, workflows, validation, traceability and security together mobilise a distributed capacity. It is not a product, a model or a document store, but a property of the configuration.

What is the difference between HumanAI and OrgAI?

It is not a difference of scale but of architecture. OrgAI is not the sum of HumanAI episodes. The constitutive threshold requires, cumulatively, authorised knowledge, processes, roles and accountability, governance with validation and contestability, security and traceability. If any is missing, the result is aggregated use, not governed capacity.

What is epistemic decoupling?

It is the distance between the range of claims AI makes accessible and the demonstrated capacity of the accountable actor to validate them, computed as the difference between the proportion of tasks with a usable answer and the proportion with a verified justification, over the same declared task set.

Do multiple AI licences amount to OrgAI?

No. Multiple licences used independently are aggregated use. A seat count demonstrates no authorised sources, roles, independent validation, traceability or controlled memory, and under audit a licence count answers no supervisory question.

What maturity levels does the framework define?

Six observable states, from M0 explorer to M5 cumulative OrgAI. A level is assigned to a bounded domain and process, not to an organisation in the abstract. The same organisation can be at M1 in one domain, M4 in another, and prohibit AI in a third.

Does the framework establish legal compliance?

No. It supports analysis and control design, but does not replace domain-specific legal assessment, data protection analysis, competent human oversight or separation of duties. The HumanAI and OrgAI labels do not replace applicable obligations.

Postal and courier: 2.00 out of 5, the weakest DNSC score. A sector that does not track its own obligations

Romania’s postal and courier sector scored 2.00 out of 5 on CyFun® control GV.OC-03.2, the weakest result in the entire DNSC series. The control requires legal, regulatory and contractual obligations relating to information security to be managed continuously, so that they remain accurate, up to date and effectively applied.

Put more directly: the control measures whether the organisation knows what the law requires of it and keeps pace with changes. A 2.00 out of 5 on that question, in a sector under new regulation, describes the problem precisely.

What was measured

The data comes from the PNRR 184 project “Creating new cybersecurity competencies for society and the economy”, in which 1,599 public and private beneficiaries self-assessed on the SecureRO platform using the CyberFundamentals (CyFun®) framework of the Centre for Cybersecurity Belgium. DNSC’s conclusion for the postal sector points to the need to strengthen processes for monitoring and continuously updating legal and regulatory requirements.

How many obligations a postal operator actually carries

On the cybersecurity side alone, the applicable framework has changed four times in two years:

  • GEO no. 155/2024, published on 30 December 2024, replacing the regime of Law no. 362/2018;
  • Law no. 124/2025, of 7 July 2025, approving the ordinance with amendments and additions;
  • DNSC director’s Order no. 1/2025, on the requirements of the registration notification process;
  • Order no. 2/2025, with the criteria and thresholds for determining the degree of service disruption and the methodology for assessing entity risk level;
  • Order no. 3 of 27 November 2025, with the supervision, verification and control rules and the risk-based prioritisation methodology.

Added to these are the instruments DNSC publishes and updates, NIS2@RO for notification, ENIRE@RO for risk level assessment, the maturity self-assessment tools for the three levels, each with its own version number. Anyone not tracking the authority’s pages systematically is working with outdated forms.

What is lost when nobody tracks

The consequences are not theoretical. Art. 18 para. (2) requires notification to DNSC for registration within 30 days of the moment the provisions become applicable to the entity. Para. (8) of the same article requires changes to registration data to be communicated within two weeks for some categories and three months for others. A change of registered office or contact person, left unreported, is a breach in itself.

Art. 12 para. (4) adds an obligation that repeats year after year: essential and important entities carry out and submit to DNSC an annual self-assessment of the maturity of their risk management measures. It is the kind of deadline that is missed quietly, because nobody has it in a calendar.

The contractual side of the control matters just as much. A courier operator has contracts with e-commerce platforms, last-mile subcontractors and parcel tracking providers. The security clauses in those contracts age: they remain written against the old regime, contain no notification obligations matching current deadlines and grant no right of verification.

The sector with the greatest public exposure

Postal and courier services have a particular feature: their names are used intensively in fraud campaigns even when their own systems have not been touched. Messages about held parcels or unpaid delivery fees circulate constantly, and recipients attribute them to the operator. The obligation to inform service recipients about significant threats does not disappear because the attack occurred outside the operator’s own infrastructure.

The obligations register therefore has to include the communication side too: who decides, within what time, through which channels and with what message. Improvisation here is visible to the public.

The three deadlines most often missed

First: the 30 days for registration notification, counted from the moment the provisions become applicable, including when they become applicable following growth in turnover or headcount.

Second: the two weeks for reporting changes to core registration data. A change of contact person is an HR operation for the organisation and a legal obligation towards DNSC, and the two do not talk to each other unless someone connects them.

Third: the annual maturity self-assessment. Being annual, it occurs to nobody at the right moment. In an obligations register with deadlines and an owner, it does.

What a working process looks like

An obligations register, kept as a living document, covers most of this control. Each row holds the legal act or contract, the applicable article, the obligation in the organisation’s own words, the deadline, the internal owner and the evidence that demonstrates fulfilment. The register is reviewed at fixed intervals and after every legislative change, and the outcome of each review reaches the management meeting.

Such a register needs no expensive tooling. It needs a designated owner with allocated time and a duty to monitor the sources, which, in practice, is exactly the missing part. Penalties under the ordinance reach EUR 7,000,000 or 1.4% of net turnover for important entities and EUR 10,000,000 or 2% for essential ones, whichever is higher.

Where to start

The first check is scope and level. The CysNis platform walks through the criteria step by step and separates legal obligations from technical recommendations.

To build the obligations register, the deadline calendar and the documentation presented at an inspection, the next step is a NIS2 compliance analysis with a remediation plan, carried out by DNSC-attested NIS auditors on the ProDefence team. Where nobody’s job description includes tracking legislation, the practical answer is an outsourced NIS2 officer who keeps the calendar and the relationship with the authority. The remaining services are in the cybersecurity services register.

A 2.00 out of 5 on knowing your own obligations is not a technical problem. It is a problem of assigned responsibility: as long as tracking the legal framework appears in nobody’s job description, it belongs to everyone, which means to no one. The first thing that changes is not a system but a line in a job description.

Data source: DNSC, “Cyber maturity score for Romania’s postal and courier sector, CyFun® control GV.OC-03.2”, 26 August 2026.

The HumanAI and OrgAI Framework Calculator, version 1.2.0

,

Version 1.2.0 of the HumanAI and OrgAI Framework Calculator is publicly available at no cost. It is a single HTML file that runs entirely in the browser: no installation, no account, and no network request of any kind. It opens unchanged on a machine with no internet connection.

The instrument accompanies the whitepaper “HumanAI and OrgAI: A Relational Framework for AI-Mediated Human and Organizational Capacity”, and turns the relationships defined there into an assessment record you complete for a concrete situation: one process, one team, one observation period.

In short

  • What it is: the digital instrument that operationalises the HumanAI and OrgAI framework, also written HumanAI and OrgAI.
  • How it runs: one HTML file, in the browser, no installation, no account, no network requests, no localStorage.
  • What it contains: eight modules and an anti-pattern detector.
  • What it produces: an on-screen assessment, a printed record of about 17 pages, and a re-importable JSON record.
  • Licence: code under MIT, conceptual framework under CC BY-ND 4.0.
  • Instrument DOI: 10.5281/zenodo.22884721 · Whitepaper DOI: 10.5281/zenodo.22295278

The problem it addresses

Every organisation that has introduced AI into a process eventually faces the same question: does it work?

The usual answer rests on two observations: people are visibly faster, and nobody has complained. Both may be true. Neither answers the question.

The difficulty is that “does it work” conflates things that must be measured separately: what the system can produce, what the accountable person can validate, who is authorised to decide, and what happens to a wrong conclusion once it enters the workflow. The framework separates them. The calculator makes them computable.

The central distinction is epistemic decoupling: the gap between the range of answers AI makes accessible and the demonstrated capacity of the accountable actor to validate them. When access grows faster than validation, an organisation produces claims it cannot support, and then reuses them.

What it looks like

Opening screen of the Human-AI and Org-AI calculator, showing the action bar, the results strip and the module navigation
Figure 1. The opening screen. The calculator starts from a worked example rather than an empty form.

Eight modules and a diagnostic panel. The modules are a sequence rather than a menu: module 02 consumes the result of 01, module 06 depends on 03, and the classification worksheet can stop everything else if the situation does not belong to the construct.

ModuleWhat it establishes
00. ClassificationWhether the situation is a HumanAI case, through a ten-question membership test
01. Epistemic decouplingThe gap between access and validation, with a confidence interval
02. Propagation exposureHow an unvalidated error is amplified by reuse, now and after declared controls
03. OrgAI thresholdWhether the six constitutive conditions are demonstrated or merely declared
04. Contribution profileOn which dimensions AI changes the outcome, in which direction, and what is lost
05. Synergy testWhether the result exceeds the relevant comparators with declared risk thresholds satisfied
06. MaturityThe M0 to M5 level for each bounded domain separately
07. OrgAI profileWhat the organisational architecture actually produces, not merely that it exists

What changed since version 1.0.0

This release began from an uncomfortable finding: in four places, the calculator contradicted its own whitepaper.

  • Material contribution was evaluated on a single dimension chosen from a dropdown, although the whitepaper defines a seven-dimension profile and explicitly forbids compressing it into a score.
  • The exported record carried none of the seven fields of the minimum reporting convention, and so was not citable under the framework’s own rule.
  • Access and validation were entered as slider values, although they are proportions over a declared task set, which manufactured an apparent precision with nothing behind it.
  • Validated organisational learning appeared disconnected from the architecture it belongs to.

All four are fixed. No formula defined in the whitepaper was altered, and the six assertions of the original test suite pass unchanged.

On top of the repairs, the missing constructs were added: the classification worksheet, an evidence reference for every organisational condition, exposure compared before and after controls, the nine-dimension organisational profile, maturity assessed per domain, the anti-pattern detector, and a JSON schema that can be re-imported.

Three things worth seeing

A profile, not a score

Contribution profile across five dimensions, with the no-AI baseline and the threshold band
Figure 2. The contribution profile across five relevant dimensions. The data come from a demonstrative case.

In the example above, AI made security alert triage significantly faster and moderately better. At the same time, confidence calibration, analyst autonomy and risk exposure all worsened, each beyond the declared threshold.

A composite score would have summed the five values and reported a gain. The result would have been technically correct and entirely misleading: part of the speed came from reduced validation. The instrument refuses to produce that number, not because of a technical constraint, but because the whitepaper forbids compressing the profile, and a single score hides exactly the trade-off that matters.

A number without a volume says nothing

Epistemic decoupling module, a gap of 0.22 measured over 140 tasks, confidence interval 0.13 to 0.31
Figure 3. A gap of 0.22 measured over 140 tasks: interval [0.13 – 0.31], gap demonstrated.
The same module at 12 tasks, a gap of 0.25 with a confidence interval that crosses zero
Figure 4. A larger gap, 0.25, but over 12 tasks: the interval crosses zero and the verdict becomes “not demonstrated”.

Access and validation are entered as counts, how many tasks out of how many, not as estimated percentages. The counts produce a confidence interval, and when that interval includes zero the instrument says “not demonstrated at this task volume”, not “no gap”.

A larger gap, poorly measured, supports less than a smaller one measured well. The instrument does not hide that difference behind the same two-decimal number.

A claim is not evidence

The Org-AI constitutive threshold with its six conditions, each carrying an evidence reference, a state and a type
Figure 5. The constitutive threshold. A condition marked without an evidence reference is highlighted and does not count towards the threshold.

Each of the six organisational conditions requires an evidence reference and its type, not a checkbox. A condition marked “demonstrated” without a reference appears as declared, undocumented, and does not count towards the threshold. The counter becomes a pair, declared and documented, and the difference between the two numbers shows the distance between what an organisation believes about itself and what it can show.

The anti-pattern detector, showing each flag with the values that triggered it
Figure 6. The anti-pattern detector: each flag shows the values that triggered it and the correction prescribed by the framework.

Across all modules runs a detector that reads the configuration as a whole and looks for contradictions between what was declared in one place and what was measured in another. It is the only component that tells the assessor something they did not know on the way in.

Properties

PropertyState
InstallationNone. One HTML file opened in any modern browser
Network requestsNone. Fonts are embedded; it works on an isolated network
Browser persistenceNone. No localStorage, no cookies
Account, database, analyticsNone exist
Security policyRestrictive CSP in the self-hosted variant, with connect-src “none”
Verification29 automated tests that extract the logic from the delivered file

The last line deserves an explanation. The tests do not hold a copy of the formulas: they extract them from the shipped file, between two markers in the code. A passing run is a statement about the file in your hand, not about a laboratory version.

Where to get it

The instrument is deposited on Zenodo with a citable DOI: 10.5281/zenodo.22884721, version 1.2.0. The record contains the source archive and the ready-to-use index.html. No unpacking is needed: the file opens directly in the browser.

The canonical whitepaper: 10.5281/zenodo.22295278.

The code is licensed under MIT, © 2026 S.C. PRODEFENCE S.R.L. The conceptual framework, the definitions and the interpretive text remain under CC BY-ND 4.0, as published in the whitepaper. In practice: the code may be reused freely, but the definitions and thresholds may not be republished in modified form under the names HumanAI or OrgAI. When you rely on the definitions or on the interpretation of the framework, cite both.

Limits

  • Results are interpretive. They do not constitute empirical validation, certification, legal advice or a compliance determination.
  • The instrument verifies nothing: every value remains a claim by the assessor until it is tied to the evidence it points to.
  • The propagation indicator is conceptual; without local calibration it does not estimate real probabilities.
  • Thresholds are declared by the user, according to domain and risk.
  • The instrument cannot be the sole basis of a consequential decision.

The last two remain permanently visible in the interface, not only in the documentation.

Interactive guide

The HumanAI and OrgAI calculator, layer by layer: the inputs, the evidence rule, modules 01–07, the ten-predicate detector and the export gate, with formulas and four computations you can run on the page.

Further reading

The framework behind the instrument, with its definitions, the constitutive threshold and the threat model, is explained in the article “HumanAI and OrgAI: what capacity has the organisation built”. A screen-by-screen walk through the modules follows in the guided tour of the calculator.

Frequently asked questions

What is the HumanAI and OrgAI Framework Calculator?

It is the digital instrument that operationalises the relationships defined in the HumanAI and OrgAI whitepaper. You complete it for a bounded situation, one process, one team and one period, and it produces a reproducible assessment record with eight modules and an anti-pattern detector.

How do I get it, and why does it need no installation?

It is a single HTML file, deposited on Zenodo with DOI 10.5281/zenodo.22884721. It opens directly in any modern browser. It has no account, database or server and makes no network request, so it behaves identically on a machine with no internet connection.

Why does it not produce a single score?

Because the whitepaper forbids compressing the contribution profile into one figure. A composite score can hide speed obtained by reducing validation. The instrument reports a profile across dimensions, with the direction and size of each change.

What does the verdict “not demonstrated” mean in epistemic decoupling?

It means that, at the declared task volume, the confidence interval of the gap includes zero. It does not mean there is no gap, only that the available data do not support one. Absence of evidence is not evidence of absence.

What is the licence and how should it be cited?

The code is licensed under MIT, while the conceptual framework, the definitions and the interpretive text remain under CC BY-ND 4.0. When you rely on the definitions or the interpretation, cite both: the whitepaper, DOI 10.5281/zenodo.22295278, and the instrument, DOI 10.5281/zenodo.22884721.

Can the results be used as evidence of compliance?

No. Results are interpretive and do not constitute empirical validation, certification, legal advice or a compliance determination. The instrument verifies nothing: values remain claims by the assessor until they are tied to the evidence they point to.

The framework, the definitions, the variables, the formulas and the interpretive model were developed by Alexandru Angheluș, an independent and self-funded author. Artificial intelligence and automation tools were used selectively for software development, structural organisation, drafting and verification activities. Responsibility for the conceptual model and for the software remains entirely with the author.

Health: 2.34 out of 5 on management training. The one CyFun control written directly into law

Romanian health sector entities scored 2.34 out of 5 on CyFun® control PR.AT-02.1, which requires members of management bodies to demonstrate that they have completed training in cybersecurity and risk management. DNSC rated the result as low and concluded that competencies at management level need strengthening.

Of all the controls measured in the DNSC series, this is the only one with a direct, explicit and mandatory counterpart in Romanian law. It is not a good practice. It is a written requirement, with a penalty attached.

What the law says, word for word

Art. 14 para. (2) of GEO no. 155/2024, approved with amendments by Law no. 124/2025, provides that members of the management bodies of essential and important entities shall complete accredited professional training, so as to hold sufficient knowledge and skills to identify risks, assess cyber risk management practices and understand their impact on the services the entity provides. The same article obliges the entity to provide professional training to all staff.

The preceding paragraph is the one that changes the tone in board meetings: management bodies approve the risk management measures, oversee their implementation and are liable for breaches of these provisions. That liability cannot be delegated to the IT department.

The word “accredited” narrows the field further: an internal one-hour briefing, however well delivered, does not produce the required evidence.

Where the score comes from

The measurement is part of the PNRR 184 project “Creating new cybersecurity competencies for society and the economy”, under which 1,599 public and private beneficiaries self-assessed on the SecureRO platform using the CyberFundamentals (CyFun®) framework of the Centre for Cybersecurity Belgium.

A 2.34 out of 5 on management training, in a sector where an unavailable system translates into postponed interventions, points to a problem of priority rather than budget. Training for management is the cheapest item in everything the ordinance requires.

What a hospital’s leadership actually decides

The decisions that matter to a healthcare provider’s security are not technical. They are management decisions, taken by people without security training:

  • whether to sign a contract with a supplier requiring permanent remote access into the hospital network;
  • whether to accept a medical device running an unsupported operating system because the manufacturer offers nothing else;
  • whether to approve the budget for separate backups or defer it another year;
  • whether, mid-attack, to pay the ransom or switch to paper procedures;
  • who speaks to the press and what is said in the first hours;
  • whether to report to DNSC within the 24-hour deadline or wait “until the situation is clearer”.

The last decision is the most expensive. Art. 15 para. (7) requires an early warning within 24 hours of becoming aware of a significant incident, notification within 72 hours and a final report within one month. Delay out of caution is, legally, delay.

The precedent written into the ordinance

The preamble of GEO no. 155/2024 explicitly cites the incident of the first quarter of 2024, in which 26 hospitals in Romania were affected simultaneously through a managed service provider. It is the only concrete case named in the ordinance’s justification, and the sector concerned is exactly the one now scoring 2.34 on management training.

The lesson of that incident was not about antivirus. It was about the supply chain, dependence on a single provider and the absence of a plan for operating without systems, all management decisions.

Training that produces evidence

The training the law requires is not a technical course. A health entity’s leadership needs to understand four things: what legal obligations the entity carries and within what deadlines; how to read a risk analysis and what to ask about it; how to make a decision in the first hours of an incident, including the decision to report; and what personal liability follows from art. 14.

The evidence is built in parallel: the course syllabus, the participant list, the certificates issued by an accredited provider, the minutes of the meeting in which management approved the measures. At an inspection, these are requested together.

The applicable penalties are real: for essential entities, fines from RON 10,000 up to EUR 10,000,000 or 2% of net turnover; for important entities, up to EUR 7,000,000 or 1.4%, whichever is higher. Order no. 3 of 27 November 2025 approved the supervision, verification and control rules, together with the risk-based prioritisation methodology.

The most common objection

The argument heard most often in healthcare is that the priority is patients, not procedures. It is a correct argument, used wrongly. An incident that stops the laboratory system, the electronic patient record or surgical scheduling affects patients directly, and in such moments nothing is improvised. What was prepared in advance is what gets applied.

The second objection is budget. Here it is worth separating what costs money from what does not: management training, the obligations register, the notification procedure, the register of suppliers with access and the testing of backup restoration are all done with working time, not purchases. The expensive part comes later, and the right order reduces even that, because you buy what is missing rather than what is being offered.

Next steps

The first check is scope: not every healthcare provider falls under the ordinance, and the resulting level changes the volume of obligations. The CysNis platform walks through the criteria with references to the legal text.

For the real state of the measures and the documentation presented at an inspection, the next step is a NIS2 compliance analysis with a remediation plan, carried out by DNSC-attested NIS auditors on the ProDefence team. Providers without an internal owner for the process can cover the role through an outsourced NIS2 officer, including preparing management meetings and handling the relationship with the authority. The full range of services is in the cybersecurity services register.

For training staff in healthcare organisations, alongside management training, the courses on CysEdu (in Romanian) and the free interactive games on CysGame (in Romanian) (phishing, ransomware, data protection) are an accessible starting point.

Data source: DNSC, “Cyber maturity score for Romania’s health sector, CyFun® control PR.AT-02.1”, 27 August 2026.

Transport: 2.68 out of 5 on data identification. The inventory that blocks NIS2 compliance

Romania’s transport sector scored 2.68 out of 5 on CyFun® control ID.AM-07.1, worded as plainly as possible: “The data the organisation stores and uses must be identified.” DNSC rated the result as low and concluded that identification and record-keeping of data need strengthening.

It is the least spectacular control in the whole series and, at the same time, the one that blocks everything else. Without knowing what data you hold and where it sits, there is no risk analysis, no classification, no continuity plan and no accurate incident notification.

Where the figure comes from

The measurement is part of the PNRR 184 project “Creating new cybersecurity competencies for society and the economy”. In total, 1,599 beneficiaries from the public and private sectors assessed their own maturity on the SecureRO platform, using the CyberFundamentals (CyFun®) framework defined by the Centre for Cybersecurity Belgium.

The control’s objective, as DNSC states it, is for all data stored and used by the organisation to be clearly identified, which supports its proper management and protection and alignment with organisational and regulatory requirements.

What “identifying data” means in a transport company

A transport operator holds data in far more places than the systems inventory suggests. Categories most often missing:

  • location and telemetry data from on-board units, stored with the fleet monitoring provider rather than with the operator;
  • tachograph records and driver data, with their own statutory retention regime;
  • transport documents, consignment notes and customs declarations, often living in mailboxes rather than systems;
  • passenger data in reservation and ticketing systems, including records held by intermediaries;
  • operational control parameters, signalling, dispatch, terminal automation, moving between the operational and office networks;
  • video archives from depots, terminals and vehicles;
  • backups hosted with third parties, whose contents nobody can describe precisely.

An inventory that does not reach these places is not an inventory. It is a list of servers.

The link to the legal obligation

Art. 11 para. (1) of GEO no. 155/2024 requires essential and important entities to take proportionate and appropriate measures to identify, assess and manage the risks affecting the networks and information systems they use. “Identify” comes first in the text for a reason: the remaining obligations are built on top of it.

An incomplete inventory produces consequences at three distinct moments:

  • at the risk level assessment, carried out with the ENIRE@RO tool provided by DNSC: the answers about systems and data determine the resulting level, Basic, Important or Essential, and therefore the volume of mandatory measures;
  • at the annual maturity self-assessment required by art. 12 para. (4) and submitted to DNSC: you cannot assess the protection of data you have not listed;
  • at incident notification, within the 24- and 72-hour deadlines of art. 15 para. (7): the question “which data was affected” is answered in hours only if the inventory existed beforehand.

Transport has an extra difficulty

In transport, the boundary between office systems and operational ones is porous. A dispatch terminal, a depot workstation or a terminal management system belongs technically to the operational technology world, yet is administered with IT accounts and IT tooling. Inventories drawn up separately, by different teams, leave between them precisely the zone through which incidents propagate.

The second difficulty is suppliers. A large share of an operator’s operational data is hosted by third parties: fleet monitoring platforms, reservation systems, freight forwarding services. The data remains the operator’s responsibility even when the infrastructure does not belong to it. A serious inventory includes the column “where it physically resides” and the column “who has access”.

An inventory that holds up

The exercise is faster than it looks if done in the right order: start from the services the organisation provides, not from the list of applications. For each service, identify the data without which the service stops, then where it sits, who administers it, how long it must be kept, and what happens if it becomes unavailable or public. The result feeds directly into the risk analysis and the continuity plan, without being rewritten.

A good inventory updates itself through process: every new service, every new supplier and every new integration passes through a step that refreshes the record. Otherwise the document is accurate exactly once, on the day it was signed.

The question asked at an inspection

Through Order no. 3 of 27 November 2025, the DNSC director approved the rules on supervising, verifying and enforcing compliance with GEO no. 155/2024, together with the risk-based prioritisation methodology for those activities. The supervisory framework is in force and works on risk criteria.

In a check, the first question is not which security products you bought, but which systems and which data you hold. An operator answering with an up-to-date document that also covers supplier-hosted systems demonstrates a working process. An operator who starts asking colleagues on the spot demonstrates the opposite, and the rest of the conversation proceeds accordingly.

There is one more practical reason to do the inventory first: it lowers the cost of every step that follows. A risk analysis run over a complete record finishes in days rather than months, and the security clauses in supplier contracts can be written concretely, against identified data, instead of in general terms that oblige nobody to anything.

Where to start

Scope comes before inventory, because it determines the level of effort. The CysNis platform walks through the criteria step by step, with references to the legal text.

To build the record itself and the documentation an inspection asks for, the next step is a NIS2 compliance analysis with a remediation plan, carried out by DNSC-attested NIS auditors on the ProDefence team. Operators without the internal resource to carry the process forward can cover the role through an outsourced NIS2 officer. The full list of services is in the cybersecurity services register.

Data source: DNSC, “Cyber maturity score for Romania’s transport sector, CyFun® control ID.AM-07.1”, 28 August 2026.

NIS2 officer in Romania: important entities must appoint one too, not only essential entities

The question comes up in almost every scoping discussion: “we are an important entity, do we still have to appoint a NIS officer?” The answer is yes, and the legal basis requires no interpretation at all. The confusion comes from a single word missing from one paragraph, and this article shows exactly where it comes from and why it changes nothing.

In short

  • Art. 14 para. (3) of Romania’s GEO no. 155/2024 requires the appointment of the officer responsible for the security of networks and information systems at both essential and important entities, expressly.
  • Para. (4) does not create the obligation. It sets the minimum profile criteria for that person, in a subset: essential entities, excluding public administration entities, micro and small enterprises.
  • The difference between the two categories lies in sanction levels and supervision mode, not in the scope of obligations.
  • The 30 day deadline runs from communication of the DNSC director’s decision on identification and entry in the register, not from the entry into force of the law.

What the text says, literally

Art. 14 para. (3) of Government Emergency Ordinance no. 155/2024, as amended by Law no. 124/2025:

“The management bodies of essential entities and of important entities establish permanent means of contact, ensure the allocation of the resources needed to implement cybersecurity risk management measures and appoint, within 30 days from communication of the DNSC director’s decision on identification and entry in the register, the officers responsible for the security of networks and information systems whose role is to implement and supervise cybersecurity risk management measures at the level of the entity.”

Both categories are named. The verb is “appoint”, not “may appoint”. There is no grey area here. Anyone claiming that important entities are exempt has to explain how they read this paragraph, and there is no way to do it.

Where the confusion actually comes from

From the next paragraph. Para. (4) sets the conditions the appointed person must meet, but limits them to part of the entities:

“The person responsible for the security of networks and information systems, provided for in para. (3), appointed within essential entities, with the exception of public administration entities, as well as micro and small enterprises … must cumulatively meet at least the following: a) has managerial authority; b) reports directly to the management bodies of the entity; c) operates independently of the IT and operational technology structures; d) has access to the resources needed …; e) has obtained an accredited specialist course, recognised by DNSC, in the field of cybersecurity, within 12 months of appointment.”

Because only essential entities appear here, people quickly reach the wrong conclusion that important entities have no obligation. That is the exact opposite of what the text says.

Three reasons why para. (4) confirms the obligation rather than narrowing it

First, and decisive: para. (4) refers back to para. (3). The wording is “The person responsible … provided for in para. (3)”. Para. (4) does not establish a new appointment; it qualifies a person whose appointment is already imposed elsewhere. For that cross-reference to make sense, the appointment must exist in both categories. A paragraph describing a person’s profile cannot abolish the paragraph that requires that person to exist.

Second, where the law does not distinguish, neither should we. Para. (3) makes no difference between essential and important. The interpretive rule is classic, ubi lex non distinguit, nec nos distinguere debemus, and applies without difficulty to a text that expressly lists both categories.

Third, the legislator knew how to distinguish and did so where it wanted to. Para. (4) does not exclude only important entities. It also excludes public administration entities, micro enterprises and small enterprises, with an express reference to art. 4 para. (1) letters a) and b) of Law no. 346/2004. That is a deliberate proportionality pattern, not a drafting slip. And if the legislator distinguished that precisely in para. (4), the absence of any distinction in para. (3) is equally deliberate.

The practical conclusion: the difference between the two categories is not whether you appoint, but whom you may appoint.

What actually differs between essential and important

RequirementEssential entity (excluding public administration, micro and small)Important entity
Appointment of the officer, para. (3)MandatoryMandatory
30 day deadline from communication of the DNSC decisionYesYes
Role: implementing and supervising the measuresYesYes
Managerial authorityRequired by lawNot required
Direct reporting to the management bodyRequiredNot required
Independence from IT and OT structuresRequiredNot required
Access to the necessary resourcesRequiredNot required
Accredited course recognised by DNSC, within 12 months of appointmentRequiredNot required

An important entity therefore has freedom in choosing the person. It may appoint someone from the IT function, without managerial authority and without an accredited course. It may, but it is worth thinking twice, for the reason set out further down.

The trap: two different training obligations, for two different people

This is the most common reasoning error on both sides of the argument, and it deserves a clear separation.

  • Para. (2) requires accredited professional training for the members of the management body, at essential and important entities. That means the director, the CEO, the board.
  • Para. (4) letter e) requires an accredited specialist course recognised by DNSC, within 12 months of appointment, for the appointed person, only in the subset of essential entities described above.

Two distinct people, two distinct obligations. The board of an important entity takes training because para. (2) requires it, independently of anything in para. (4). Confusing the two leads either to believing that para. (4) “forgot” important entities, or that para. (2) applies to the appointed officer. Neither reading survives contact with the text.

The same distinction produces the split that matters in practice: execution responsibility belongs to the appointed person, while accountability stays with the management body under para. (1). The function can be delegated; the accountability cannot.

How the authority itself reads art. 14

DNSC has drafted a decision approving the training standard for members of management bodies and the list of recognised certifications. It is a draft, watermarked DRAFT, and not a legal act in force, so it cannot be cited as a legal basis. It is, however, the clearest public indication of how the authority itself reads art. 14, and that reading confirms everything above.

The declared scope of the standard covers both categories: the title speaks of “the training standard for the members of the management bodies of essential and important entities”, and the qualification level is defined as “Strategic / Executive Management, essential and important entities”. There is no separate, lighter version for important entities.

One of the six competence units is the appointment duty itself. Unit 3, “Organisation, Delegation and Resource Allocation”, declares its source as “GEO 155 Art. 14(3)” and is described as follows: “This unit details how the manager fulfils the legal obligation to ‘appoint’ responsible persons and to ‘supervise’ their activity.” Its first competence element requires the manager to use “the European ENISA ECSF ‘CISO’ profile and the provisions of paragraphs (3) and (4) of GEO 155/2024″ to define the job description, objectives and KPIs, to establish “reporting lines that ensure the CISO’s independence from the IT department”, and to issue “the formal appointment decision in accordance with legal requirements”.

In other words, the authority teaches the appointment as an executive duty of the management of any entity within the scope of the ordinance, and the independence criterion, which in the law appears only in para. (4), is presented as a competence element for the management of both categories. Legally that does not turn the criterion into an obligation for important entities. Practically, it shows plainly what the authority expects.

The draft also states for itself what the difference between the two categories consists of. Under the “Range of Variables” of the first competence unit: “Type of entity: Essential (critical sectors, maximum sanctions) vs. Important (slightly reduced sanctions, ex post supervision).” The difference is one of sanction level and supervision mode, not of the scope of obligations.

The same draft is what names the art. 14 (3) and (4) officer “CISO”, taking the role profile from the European ENISA ECSF framework. If it is adopted, this will become the authority’s de facto terminology, although the legal designation remains “officer responsible for the security of networks and information systems”. The standard is analysed in detail in the article on the DNSC draft training standard for management bodies, which we publish on 29 September.

The 30 day deadline: when it actually starts

This deserves to be said plainly, because it is the only real argument available to those who are waiting. The 30 day deadline does not run from the entry into force of the ordinance, but from communication of the DNSC director’s decision on identification and entry in the register. An entity that has not yet received that decision does not have the clock running.

That is not an exemption, though, it is a deferral of a procedural deadline. The substantive obligation stands, and 30 calendar days are enough to sign a decision, not to find the right person, build their job description, establish the reporting line and secure their independence from IT. Organisations that start only after receiving the decision predictably end up with a formal appointment made in haste, exactly the kind of evidence that collapses at the first inspection.

What an important entity actually risks by waiting

Failure to comply with the obligations in art. 14 is sanctionable in both categories. The maximum caps are higher for essential entities than for important ones under the ordinance’s sanctions regime, but a lower cap is not an exemption from the obligation.

The difference in mechanism matters more. Essential entities are subject to ex ante supervision, meaning they can be checked proactively. Important entities are subject to ex post supervision, which means the check usually comes after an incident or a complaint. The moment at which an important entity has to show who the appointed officer was, what duties they had and what they did is, statistically, the worst possible moment: mid investigation, with the service degraded and the press on the story.

And here is the argument that should weigh more than the letter of the law. At important entities the para. (4) criteria are not mandatory. But an officer reporting to the very structure they are supposed to control, with no managerial authority and no budget, is the first observation any auditor writes and the first weakness any post incident analysis exploits. The law permits it; risk management does not recommend it.

What to do in practice, in the right order

  1. Confirm your classification. Essential or important, on what criterion, in which sector. Everything else follows, including which profile criteria apply to you.
  2. Choose the person before the DNSC decision arrives. The 30 days are for formalisation, not for recruitment.
  3. Issue the appointment decision, with duties, reporting line, indicators and a firm date.
  4. Document the independence, even as an important entity for which the law does not require it. It costs one line in the org chart and it saves your file.
  5. Connect the appointment to the rest of the file: the approved security policy, the signed risk register, the incident reporting procedure with its 24 hour and 72 hour deadlines, and the minutes of a risk review meeting.

For the first step, the CysNis platform walks through the classification criteria step by step and separates legal obligations from technical recommendations, so the board discussion starts from a clear status rather than an assumption.

For steps three to five, the documents do not have to be invented from scratch. The NIS2 documentation packages contain editable templates for appointment decisions, job descriptions, policies, registers and procedures. If you would rather first know how far you are from the requirements, the starting point is a NIS2 compliance assessment with a remediation plan, carried out on evidence rather than declarations. Members of the ProDefence team are DNSC-attested NIS auditors.

Where no internal person can cover the role, and especially where the only candidate would be the head of IT, which is precisely the situation the independence criterion is designed to avoid, the role can be covered through an outsourced NIS2 officer, accountable for deadlines, documentation and the relationship with the authority. Which approach fits the organisation, in-house, consultant or outsourced role, is compared in the article on implementing NIS2 requirements in Romania, three routes.

Frequently asked questions

Do important entities have to appoint a NIS2 officer?

Yes. Art. 14 para. (3) of GEO no. 155/2024, as amended by Law no. 124/2025, requires the appointment by the management bodies of essential entities and of important entities alike. The text lists both expressly.

Then why does para. (4) mention only essential entities?

Because para. (4) does not govern the duty to appoint, but the minimum conditions the appointed person must meet. It refers expressly back to para. (3), so it presupposes that the appointment already exists in both categories. The limitation applies the proportionality principle, in the same way as the exclusion of public administration entities, micro and small enterprises in the same paragraph.

At an important entity, can the officer be the head of IT?

The law does not forbid it, because the independence requirement from IT and OT structures sits in para. (4), which applies to essential entities. From a risk management perspective it is a weak choice: the person controlling the measures ends up reporting to the structure they control, and that conflict of interest is the first observation in an audit or a post incident analysis.

When does the 30 day appointment deadline start?

From communication of the DNSC director’s decision on identification and entry in the register, not from the entry into force of the ordinance. The substantive obligation exists independently of that procedural deadline, and 30 days are not enough to recruit and prepare the right person.

Does the appointed officer need a certification?

An accredited specialist course recognised by DNSC, obtained within 12 months of appointment, is required by para. (4) letter e), so in essential entities, with the exceptions stated in the text. The law does not impose this condition on important entities.

Can the role be outsourced?

The law speaks of appointing a responsible person and, at essential entities, of criteria on authority, reporting, independence and access to resources. Covering the role through an external provider is widely practised, provided the duties, the reporting line and the contractual accountability are documented. The management body’s own accountability under para. (1) stays with the entity in any case.

What is the real difference between an essential and an important entity?

The level of the sanction caps and the supervision mode. Essential entities are subject to ex ante supervision, important entities to ex post supervision, usually triggered by an incident or a complaint. The risk management and governance obligations in art. 11 to 14 apply to both.

The analysis above is a technical reading of the text of GEO no. 155/2024, approved with amendments by Law no. 124/2025. It is informative and does not constitute legal advice. The DNSC draft decision cited is watermarked DRAFT and is not a legal act in force.

Managed ICT services: 2.88 out of 5 on automation. Providers are checked twice under NIS2

Romania’s managed ICT service providers scored 2.88 out of 5 on CyFun® control ID.IM-03.6, which requires organisations to implement, where feasible, automated mechanisms to support information sharing and collaboration. DNSC rates the result as low and recommends strengthening automation to improve operational efficiency, accuracy and security.

This score carries particular weight. ICT service management is not just another sector in the annexes of GEO no. 155/2024: it is the sector through which everyone else’s networks pass. When the provider is late, the client is late too, and the client has legal deadlines of 24 and 72 hours.

The measurement in context

The data comes from the PNRR 184 project “Creating new cybersecurity competencies for society and the economy”, in which 1,599 public and private beneficiaries assessed their own maturity on the SecureRO platform using the CyberFundamentals (CyFun®) framework of the Centre for Cybersecurity Belgium.

Being a self-assessment, the figure reflects how organisations see themselves. When a technical sector’s own view of its automation stops at 2.88, the verifiable situation is usually more modest still.

What “automated information sharing” means

The control’s objective is to improve the efficiency, accuracy and security of information sharing and collaboration. In practice, a managed service provider works with dozens of clients, each with its own contact, channel and reporting format. Without automation, every security advisory becomes a manual operation: someone reads the bulletin, someone decides who is affected, someone writes the messages, someone chases the replies.

What real maturity looks like on this control:

  • a register of clients, the services delivered to each and the technologies involved, updated automatically from management systems rather than kept in a file;
  • indicator-of-compromise feeds ingested and correlated automatically, not read by hand out of e-mail;
  • notification of affected clients triggered from the system, with delivery and acknowledgement recorded;
  • integration between monitoring, ticketing and incident handling, so that an incident timeline builds itself;
  • secure channels for exchanging information with DNSC, with clients and, where relevant, with other providers in the chain;
  • reports generated from data rather than assembled manually on request.

The last point is felt fastest. A final incident report written by hand a month after the event, from memory and screenshots, looks exactly like what it is.

Why the deadlines matter

Art. 15 para. (7) of GEO no. 155/2024 sets a tight calendar for significant incidents: an early warning within 24 hours of becoming aware, an incident notification within 72 hours, an interim report at the request of the national incident response team, and a final report within one month of the notification.

A provider who discovers that an exploited vulnerability affects, say, 40 clients has two problems at once: its own reporting and informing clients, who have the same clock running. Without automated mechanisms, the order in which clients are told becomes arbitrary, and some of them find out from the press.

The preamble of the ordinance explicitly cites a case from the first quarter of 2024 in which 26 hospitals in Romania were affected simultaneously through a managed service provider. The legislator drafted the text with that incident in mind.

The provider is checked twice

A managed ICT service provider occupies a double position under GEO no. 155/2024. On one hand it is itself an entity that notifies DNSC for registration, assesses its risk level and submits an annual self-assessment of the maturity of its measures under art. 12 para. (4). On the other, it is a link in every client’s supply chain, and clients have their own obligation to manage that chain’s risk.

The commercial consequence already shows up in tenders and contract renewals: the client asks for proof that the provider is registered, that it has notification procedures, and that it can deliver, in a usable format, the information the client needs for its own 72-hour report. A provider who cannot answer loses the contract before price is discussed.

The penalties reinforce the interest: for important entities, fines from RON 5,000 up to EUR 7,000,000 or 1.4% of net turnover; for essential entities, up to EUR 10,000,000 or 2% of net turnover, whichever is higher.

The two-hour test

A simple exercise reveals where a provider actually stands, whatever the declared score. Pick a real vulnerability published in recent months, in a product the provider administers for several clients. Then time two things: how long it takes to say exactly which clients are affected, and how long it takes to prove that all of them were notified.

If the first answer requires a morning of searching through configuration files, the register does not exist. If the second requires searching colleagues’ mailboxes, notification is a habit rather than a process. Both translate into an incident report written under pressure, inside the 72-hour window, with details that contradict each other.

What can be done without year-long projects

Automation on this control does not require a new platform. It requires the information already held in systems to move without human intervention: the client register linked to the technology register, advisories linked to the register, notifications linked to advisories, acknowledgements linked to notifications. Most providers have every piece and no connections between them.

The first step is knowing exactly what is required. The CysNis platform separates legal obligations from technical recommendations and allows scope to be checked before any investment.

For the gap between what exists and what has to be demonstrated, the next step is a NIS2 compliance analysis with a remediation plan, built on evidence. Members of the ProDefence team are DNSC-attested NIS auditors. Providers who would rather not load their technical team with the administrative side can cover the role through an outsourced NIS2 officer, including the relationship with the authority and the answers owed to clients. The remaining services are listed in the cybersecurity services register.

Data source: DNSC, “Cyber maturity score for ICT Service Management in Romania, CyFun® control ID.IM-03.6”, 9 September 2026.

Skip to content