Frequently asked questions

SpineTech is a European technology company that delivers AI training, automates internal processes and builds B2B and B2C applications and custom software for SMEs. We help businesses save time and make money through intelligent automation and software that truly fits the way your organisation works.

Three things: (1) Senior expertise, directly accessible — no account managers, no juniors learning on your budget. (2) AI integrated into every project — from discovery to delivery, not as a gimmick. (3) Our proprietary Spine5 methodology — a structured, repeatable approach that guarantees transparency and predictability.

10+ years of hands-on experience across startups, scale-ups and large corporates, with a track record in large-scale migration projects and implementing business applications. For the build we work with senior developers we select per engagement. We know what works, what fails — and why.

Our office is located at Carl Perkinstraat 19, 4337 RH Middelburg, Netherlands. SpineTech is registered with the Dutch Chamber of Commerce (KvK) under number 82532923. All our solutions are hosted on European infrastructure.

We work from three business lines, in the order they logically follow one another — you can join at any of them:

Training — AI readiness sessions and the mandatory AI literacy under Article 4 of the EU AI Act, including the record-keeping that proves it.

Automation — Internal processes that cross system boundaries, set up with Copilot, Claude or whatever demonstrably works better.

Apps & custom — B2B and B2C applications, client portals, CRM and Power Platform, system integrations, dashboards and fully bespoke software.

An AI agent is software that independently executes tasks, reasons about context and communicates with people and systems — within boundaries you define up front. We build them deliberately semi-autonomous: routine work runs through, but for any action carrying customer, financial or legal impact the agent prepares a draft and a human signs off. That is not only safer, it is what the EU AI Act asks of you.

We have playbooks for governance (AI register, validation log, audit trail), HR (vacancy copy, scheduling, onboarding administration — explicitly not the assessment of candidates), customer service (routing, status updates, FAQs drawn from an approved knowledge base), IT (monitoring, diagnosis, prepared remediation), sales (lead enrichment, follow-up, reporting) and marketing (SEO content, social media planning, A/B reporting) — each with editorial or operational approval by a human.

Yes. Article 4 of the EU AI Act requires every organisation that uses AI to ensure a sufficient level of AI literacy among its staff — including organisations that only use off-the-shelf tools such as ChatGPT or Microsoft Copilot. The duty has applied since 2 February 2025; supervision and enforcement by the Dutch authorities began on 2 August 2026. There is no mandatory exam or certificate, but you must be able to demonstrate what you have done: an inventory of your AI use, an internal policy, instruction per role and a record of who completed which training.

If your processes sit close to the standard and you are already inside the Microsoft ecosystem, configuring Dynamics or Power Apps is usually faster and cheaper. We choose bespoke when you have a process that fits nowhere else — a workflow that lives in someone's head, a spreadsheet held together with hope, or an integration that never quite works. We work through both scenarios with you, including licence costs over three years.

We follow our proprietary Spine5 methodology in 5 phases:

Insights (1–2 weeks) — Strategy & discovery.
Details (1–3 weeks) — Analysis & modelling via Domain Driven Design.
Development (weekly sprints) — Iterative build with continuous feedback.
Testing (1–2 weeks) — Functional, technical and UAT.
Production — Go-live, handover and ongoing support.

After every sprint you receive tangible results and can steer directly. No waiting months for a big-bang release. You get weekly demos, a live staging environment and weekly progress reports.

Yes. Go-live is the beginning, not the end. We guide the launch, ensure a smooth handover, provide your team with training and documentation, and offer post-launch support so your team can operate fully independently.

The solutions we build for you run on European infrastructure and are fully GDPR-compliant. Your business data stays in Europe.

For every integration we record which agent may touch which system, and how far — the principle of least privilege. Where an application processes personal data at likely high risk, a DPIA belongs with it; we plan that into the Details phase rather than repairing it afterwards.

About this website itself we are equally precise: which processors we use for it, and where they process, is named in our privacy statement. We think you may expect that distinction from a firm that publishes on compliance.

We work with model routers and standardised interfaces, so you can integrate with any LLM of your choice — including self-hosted models. You're not locked into one provider, and your architecture stays future-proof as models evolve.

Safety is built in by design. Every agent has identity-bound permissions, mandatory human-in-the-loop checkpoints for critical decisions, and kill-switches with rollback options. We also provide comprehensive logging and real-time alerts, keeping your systems audit-ready at all times.

Concretely, "goes wrong" means two things. If the output goes wrong, human validation catches it before anything leaves the building. If the system goes wrong, one designated person holds both the authority and the technical means to stop the agent instantly and reverse its actions.

No. Our philosophy is co-creation, not replacement. AI agents take over the administrative burden, so your people can focus on work that truly adds value. HR focuses on people; the agent handles the paperwork.

The AI Act — formally Regulation (EU) 2024/1689 — sorts AI applications by risk and attaches obligations to each level. The higher the risk, the heavier the requirements on documentation, data quality, human oversight and security.

At its core it shifts the burden of proof: a regulator does not have to show your AI went off the rails — you have to show you are in control. That only works with a file that grows with the system: a register of what runs where, logs of what happened, and recorded validations of who approved what.

A number of applications fall into the unacceptable risk category and are simply not allowed:

• Social scoring — classifying or scoring citizens based on social behaviour or personal characteristics.
• Predictive policing by profiling — predicting that someone will commit a crime purely from personality traits.
• Real-time remote biometric identification in public spaces for law enforcement, barring strictly limited exceptions.
• Biometric categorisation inferring sensitive traits such as race, political opinion, religion or sexual orientation.
• Untargeted scraping of faces from the internet or CCTV to build recognition databases.
• Subliminal manipulation exploiting vulnerabilities to influence behaviour harmfully.
• Emotion recognition in the workplace or in education.
• Nudifier apps and the generation of child sexual abuse material — recently added to the list.

If such an application comes up in a conversation, we do not build it. That is not a negotiating position.

Broadly in two cases. First, if the system sits in one of the critical domains of Annex III: recruitment and selection, education, credit scoring, medical diagnostics, critical infrastructure and law enforcement. Second, if it is a safety component of an already regulated product, such as machinery or medical devices.

Note the nuance: it is about the application, not the technology. The same language-model architecture is minimal risk in a marketing assistant and high risk the moment it ranks candidates. That is why we classify per use case, not per tool.

It matters because the heaviest obligations sit with the provider: conformity assessment, technical documentation, registration and CE marking. As a deployer you use someone else's system and carry a lighter — but not empty — set of duties.

The trap: you legally become the provider the moment you put your own brand name on a high-risk system, or change its intended purpose such that it lands in the high-risk category. Many organisations drift into the provider role without noticing. We determine that role in the Insights phase, so you know before you build rather than after.

It is the mandatory procedure establishing that a high-risk system meets every requirement before it goes to market or into use. The responsibility sits with the provider.

There are two routes. For most Annex III systems you may run the assessment yourself through an internal procedure. For specific cases — certain biometric systems, or situations where harmonised standards are absent or not followed — an independent notified body must be involved.

There is no counter where you file an application; it is a process you run yourself:

1. Establish that the system is high risk.
2. Carry out the conformity assessment — internally or via a notified body.
3. Register yourself as provider and the system in the central EU database.
4. Draw up and sign the EU declaration of conformity.
5. Affix the CE marking visibly, legibly and indelibly to the system, its packaging or the accompanying documentation. Where a notified body was involved, their identification number goes alongside it.

Affixing a CE marking without grounds is not administrative sloppiness but an infringement, with fines up to €15 million or 3% of annual turnover.

The EU declaration of conformity rests on a set of concrete obligations from Articles 8 through 17 of the AI Act:

• Risk management system (Art. 9) — identify and mitigate risks across the full lifecycle.
• Data governance (Art. 10) — high-quality, representative datasets to prevent bias.
• Technical documentation (Art. 11) — design, algorithms, logic applied and data governance.
• Logging (Art. 12) — automatic recording of events.
• Transparency (Art. 13) — clear instructions for use.
• Human oversight (Art. 14) — the system must be designed so trained people can intervene.
• Accuracy and cybersecurity (Art. 15) — demonstrable robustness against technical faults and external threats.
• Quality management system (Art. 17) — from design through after-care.

On top of that, where applicable, a DPIA under Article 35 GDPR — a separate instrument, Regulation (EU) 2016/679 — and a fundamental rights assessment (FRIA).

The prohibitions already apply. For the heavier obligations these are the reference dates:

• 2 December 2027 — standalone high-risk AI systems, such as HR tools.
• 2 August 2028 — AI embedded in regulated products, such as lifts or medical devices.

That sounds distant, but a conformity file is not built in a quarter. Systems you design today without logging, risk classification and an oversight structure will have to be opened up and rebuilt by then. Building it in up front is considerably cheaper than repairing it later.

Oversight only exists once you can show it to a regulator. That takes four things at once:

Roles — name who is responsible per application, and demonstrate that this person has the knowledge, training and formal authority to intervene. Put it in the job description.

Policy — record the validation duty: AI output is a draft until a human has checked it. Document the escalation path for anyone who spots an error or bias.

Audit trail — keep a validation log of who approved what and when. For high-risk systems, retain logs for at least six months. Where there is customer impact, note explicitly in the file that AI was used and verified.

Training — include AI literacy in your training policy and record that staff were instructed on how the system works, its limits and its risks.

Prompt injection is the hiding of instructions inside material an AI processes — an email, a website, a PDF. The model distinguishes poorly between your instruction and one sitting in the text it reads, and can be hijacked as a result: leaking data, taking unwanted actions, introducing security holes.

No watertight technical fix exists. So we defend in layers:

1. System instructions — instruction isolation (external text is source content, never a command) and reporting behaviour: on a suspicious instruction the agent halts, quotes the text and asks for confirmation.
2. Human-in-the-loop — the primary line of defence. No independent actions with customer or financial impact; the agent prepares drafts, a human checks for illogical or deviant conclusions.
3. Technical filters — output validation for unwanted patterns and sensitive data, restricted permissions under least privilege, and caution with RAG the moment third-party documents enter the knowledge base.
4. Organisational — a validation duty in policy, a clear escalation path and training in recognising injection attempts.

An AI register is the overview of which AI applications run inside your organisation, for what, at which risk classification, who owns them and how quality control is arranged per process. Think of it as the internal whitelist: which tools are permitted for which work.

You need it because it is the starting point of every conversation with a regulator. Without a register you cannot demonstrate that you have an overview, let alone that you are in control. Every agent we deliver feeds the registration automatically — not a separate spreadsheet that falls behind within three months.

In principle the AI Act does not apply to free and open-source software; the legislator does not want to hold back open development. But that exemption lapses immediately in two cases: for prohibited applications, and as soon as the software is deployed in a high-risk context such as recruitment or credit scoring.

Separately, under the Product Liability Directive open source is only exempt where it is supplied outside commercial activity. Integrate open-source components into a commercial product or paid service and you can certainly be held liable for damage caused by defects.

A practical point: if you use an open model through an external API, check where processing physically takes place. Not every provider processes within the EU, and that bears directly on your GDPR position.

Deploying or supplying prohibited AI applications carries fines up to €35 million or 7% of global annual turnover, whichever is higher. Other infringements, such as affixing a CE marking without grounds, carry a maximum of €15 million or 3% of annual turnover. For SMEs, the lower of the two figures is generally applied.

Five risks, none of them theoretical:

No copyright — purely AI-generated code carries no automatic copyright. Only where a human demonstrably held creative direction is the code protected. Otherwise anyone may copy your architecture.

Loss of technical understanding — at some point nobody knows precisely what is in there. Fixing bugs then becomes impossible without expensive outside help.

Lack of originality — fully AI-generated software looks alike. A competitor doing the same gets a comparable product.

Increased liability — under the new Product Liability Directive, software and AI count as "products". If your code causes damage, a court may more readily presume the cause lies with the product where the technology is complex.

Prompt injection — agents that write code from external input are especially vulnerable to hijacked instructions.

Our line: AI prepares drafts, a senior developer reviews, validates and takes responsibility before anything goes live. We record that review process, so it is demonstrable that humans hold the reins.

In principle a transparency obligation applies to AI-generated content, and users must know when they are communicating with an AI system rather than a person.

There is one relevant exception: where you inform the public on matters of general interest and the content has been subject to substantive human review or editorial control, the specific labelling obligation falls away. Which is exactly why we record that editorial step rather than keeping it informal — the difference between "somebody had a look at it" and a demonstrable edit is legally material.

A substantial modification to a high-risk system requires recertification: the conformity cycle starts again. The same applies if you change the intended purpose — which can additionally shift you from deployer to provider.

So we treat recertification as part of regular maintenance. You know in advance which change restarts the cycle, so a release never catches you out.

Yes. Prohibited applications we do not build, full stop. And for high-risk applications that are technically fine but organisationally unsupported — no designated supervisor, no validation capacity, no willingness to keep logs — we say so up front.

Describe your process and we classify the risk. You will hear from us what is allowed, what is possible, and what we would not build. That last conversation is usually the most valuable.

No. We specialise in building AI systems that demonstrably stay within the lines, not in giving legal advice. These answers reflect the position we work from when designing solutions. For a binding view on your specific situation — particularly around the provider role, liability and declarations of conformity — consult a lawyer. We are happy to work alongside yours.

Sources. Article references on this page are to Regulation (EU) 2024/1689 (the AI Act) unless stated otherwise. Article 35 refers to Regulation (EU) 2016/679 (the GDPR). The Product Liability Directive is Directive (EU) 2024/2853. We summarise in plain language; in case of doubt the text of the regulation governs.

That depends on the solution. An AI readiness session is usually scheduled within two weeks. Training: weeks. Automating internal processes: weeks. An application or full custom development: depends on scope, but always in sprints of 1–2 weeks with interim deliverables.

That depends on the solution. Readiness sessions and training are priced at a fixed rate. For automation, applications and custom work we define scope, timeline and budget during the Insights phase. No surprises afterwards.

Schedule a 30-minute introductory call — straight to the point. Or send us a message via the contact form.