Skip to main content
FromNine
Menu

Our approach

Understand. Design. Build. Operate.

Every engagement passes through four stages, and each stage closes with a result you can check and retain: a defined problem, an architecture with agreed measures of success, an implementation that has been tested, and a handover together with an operating plan.

Ministries, public entities and companies in Malta go through the same four stages as our clients elsewhere in the EU.

Start a conversationOur AI testing

Four stages

From the first meeting to a system in daily use

Every stage produces a named result and gives your team a defined role.

  1. Understand

    We study the business problem, the people it affects and the systems you run, and together we judge whether AI is the right tool for it at all.

    What we do

    • Interviews with the staff who carry out the work now
    • A look at systems, access to data and limitations
    • Initial assessment of risk, privacy and classification under the AI Act
    • A short list of opportunities, each with the measure we would use

    Output

    • Problem definition

    Your part

    Brief us on the context, bring the right colleagues to the table and set the priorities.

  2. Design

    We select an architecture, settle what success means and plan the first release, including the way quality, security and human oversight will be demonstrated.

    What we do

    • Architecture drawn up, integrations designed
    • Evaluation plan with test sets and quality criteria for the AI
    • Design for security, data protection and human oversight
    • Release plan and composition of the team

    Output

    • Architecture and success measures
    • Release plan

    Your part

    Sign off measures and priorities, and settle the questions on data, hosting and oversight.

  3. Build

    Work arrives in small increments, each one tested, that you can open and try for yourself; a second engineer checks every change, and tests and documentation are added at the moment it is merged.

    What we do

    • Each increment shown on software that runs
    • Automated tests, code review and security scans
    • AI output measured against the criteria you approved
    • Documentation produced together with the code

    Output

    • Tested implementation
    • Evaluation results

    Your part

    Look at every increment, put it in front of actual users and sign off whatever is finished.

  4. Operate and improve

    Depending on your preference, your staff take over the system or we keep running it; either way we follow its behaviour once live and refine it with you according to real usage.

    What we do

    • Tracking of quality, running cost and response time
    • Going through escalations and doubtful cases
    • Runbooks and transfer of knowledge to your staff
    • Improvement releases at regular intervals

    Output

    • Handover and operating plan

    Your part

    Decide whether you run the system yourselves or who does, and pick which improvements follow.

The cycle then repeats: lessons from live operation set the agenda of the following round.

How we collaborate

Working side by side with your staff

A single team with common aims, progress you can see and decisions kept on file.

  • A single lead who answers to you

    You deal with a single delivery lead who is accountable for scope, quality and progress, with architects and specialists joining when the work needs them.

  • One team, one backlog

    Specialists from both sides draw on one shared backlog. Priorities are agreed with you, and every change can be seen by everybody on the programme.

  • A regular pace

    Short planning cycles, demonstrations on running software and reviews at fixed intervals, so problems come to light early instead of at the end.

  • Decisions in writing

    We record each architecture and design decision with the reason behind it, so it can be reopened, explained to others and passed on.

Governance

Defined roles, open risks, managed change

  1. A steering group that takes decisions

    A small steering group meets at set intervals to settle scope, priorities and risks. How issues are escalated is agreed at the outset, before anyone needs it.

  2. Risks kept visible

    One register holds every risk, dependency and assumption, each with a named owner, and it is on the agenda of each steering meeting.

  3. Governance specific to AI

    Every AI system gets a file stating what it is meant to do, how it is classified for risk, which data it draws on and at which points a person takes the decision. That is what the AI Act asks of providers and deployers, and in Malta the MDIA leads market surveillance under it.

  4. Managed change

    Changing the scope, the data or how a model behaves goes through a change procedure agreed in advance, which shows the consequences for cost, quality and compliance before anyone approves it.

Quality assurance

The AI is tested like the rest of the production system

We engineer the quality of the software and of the AI together, starting with the first increment.

  • Automated testing

    The delivery pipeline runs unit, integration and end-to-end tests automatically; if even one fails, the release does not proceed.

  • Review and security scans

    No change ships before a second engineer has reviewed it. Dependencies, code and infrastructure are scanned automatically, and every release has its own planned security tests.

  • Accessibility testing

    Interfaces are checked for WCAG 2.2 level AA, by automated tools and by testers working with screen readers and other assistive technology.

  • Evaluation of AI output

    Together with you we set quality criteria and test sets, measure the AI output against them before release and continue measuring afterwards. Where the system is unsure, the decision goes to a person.

Evaluating AI before and after it goes live

The cycle of evaluation we set up with you for each AI feature. The criteria, thresholds and review steps are decided for each use case.

Read the diagram as text

A cycle of five steps is shown.

Step 1, criteria and test set: the quality bar is fixed with your specialists, together with a collection of genuine examples. Step 2, evaluation before release: the AI output is scored on those examples using that bar. Step 3, release decided by a person: you see the scores with us and choose whether the feature is switched on. Step 4, monitoring in production: answer quality, running cost and response time are followed during real use. Step 5, review of unclear cases: staff take over whatever the AI cannot handle with confidence.

What staff decide in step 5 flows back into the test set of step 1, so every new round of evaluation builds on what real use has taught.

Documentation and handover

Code is only part of what stays with you

Handover planning starts in the first week, so that your organisation can run and adapt the result without us.

  • Architecture documentation

    Diagrams and written descriptions of components, integrations and data flows, revised each time the system changes.

  • Decision records

    The reason for every important choice, the alternatives we weighed and what would lead us to reconsider it.

  • Runbooks and operating plan

    Instructions for deploying, monitoring, restoring and supporting the system, and a clear split of duties after go-live.

  • Knowledge transfer

    Your future system owners pair with our engineers, join walkthroughs and attend handover sessions throughout the engagement, so transfer is not left to the final weeks.

Delivery teams

Teams chosen from 2,400+ people

Our teams combine disciplines and are chosen from 2,400+ colleagues working in AI engineering, software, cloud, data and integrations, and in our Salesforce, SAP and Odoo practices. A team begins small and grows as the work requires, from a handful of people in discovery to a complete programme.

Continuity matters to us: we try to keep the people who design your system on it until handover, because that is how a project turns into something that lasts. Team composition, and the way it fits with your own staff, is settled per engagement. Delivery happens from Antwerp, Ghent and Amsterdam, in English.

Public sector

Working with Government and public entities

What we learnt on 600+ public-sector projects in EU Member States guides how we work with ministries, departments and public entities. The tender phase, the Public Procurement Regulations (S.L. 601.03) and the documents a call for tenders on ePPS asks for are part of the plan from the start.

Accessibility, security, data protection and services in both official languages, Maltese and English, are treated as requirements during discovery and design, not left for the last round of tests. We record decisions so that they can be explained to auditors, to authorities such as the Information and Data Protection Commissioner (IDPC) and to the public.

Malta

Delivery that takes Maltese law into account

A Maltese programme raises its own questions early on. Which duties of the AI Act apply, now that Legal Notices 226 and 227 of 2025 have named the MDIA and the IDPC as authorities? How is personal data protected under the GDPR and the Data Protection Act (Cap. 586)? Is the organisation in scope of the NIS2 Order, in force since 23 January 2026, and what will the Cyber Resilience Act require of software with digital elements?

We answer these during the Understand and Design stages, so they inform the architecture and do not hold up the release. Where Maltese rules go further than the EU text, the plan states it plainly. The legal interpretation itself is for your own advocates.

Common questions about our way of working

How much time does each stage need?

That depends on the scope, the systems concerned and how fast decisions can be taken. At the outset we agree a plan for every stage, and you can follow progress throughout. We do not commit to durations until we understand the problem.

Is it possible to begin on a small scale?

Yes. Many clients begin with the Understand stage alone, or take one use case through all four stages before going further. Each stage delivers something you can use, even if you then choose to continue without us.

What remains with us at the end?

Your staff receive the documentation, decision records and runbooks required to run and adapt the system, and planning for handover starts on day one. The agreement for each engagement sets out who holds the code and the intellectual property.

How do you check that the AI output is good enough?

Your specialists and we set quality criteria and test sets, we evaluate before each release and we continue measuring once the system is live. Cases the system is unsure of go to a person. We report the evaluation results and do not promise accuracy percentages.

Can our staff and other suppliers be part of the same effort?

Yes. Mixed teams and work next to other suppliers are common for us. Defined interfaces, one shared backlog and decisions in writing make it clear who is responsible for what.

Can you work within the Maltese public procurement rules?

Yes. Tender procedures, and the paperwork that comes with them, are a familiar part of our 600+ public-sector projects in EU Member States. If you have a call for tenders on ePPS in mind, send us its reference and the right team will pick it up.

Begin with the problem

Describe the problem in front of you and the systems already in place. We will recommend a starting stage and explain what you would have in hand when it ends.

Start a conversationSee our services