AI integration

Open-weight models on your hardware or in the cloud, or closed models by API, applied where they pay.

What it is

AI is not a goal in itself. There is a lot of hype around it, and most things can still be done without it at a fraction of the cost. We apply it only where it brings a measurable, significant gain in a specific part of a business process.

That is Cloudtech’s position, and it shapes the service. AI integration starts with a process and a question, not with a model. Where a report, a rule or a statistical test answers the question, that is what gets built. Where a language model adds something measurable, Cloudtech integrates one: open-weight models served on local GPUs and attached to the outputs of a governed data pipeline, or a closed model by API where the data allows it.

A language model on enterprise data needs three things. It needs the right data and nothing more: past a point, every extra retrieved passage lowers answer quality.¹ It needs rules that stop the obvious misreadings. And it needs an honest way to say it does not know: measuring uncertainty and refusing uncertain questions raises accuracy.² Cloudtech treats all three as engineering requirements, and adds a fourth. A model that reads documents and uses tools can be attacked through them, so it is secured like any other system that handles your data.

What we do

• Analysis on aggregates. The model reads aggregates computed by the pipeline, never raw records. Benchmarks on real enterprise databases show why: the best model agent completed 21.3% of the tasks, against 91.2% on the older academic set.³ The payload is trimmed to one focus and annotated with what each figure means. The model returns findings with their evidence, recommended actions and a confidence level, in a fixed structure the application can check.
• Retrieval over documents and records. Answers from manuals, procedures, reports and records, with their sources cited. Scanned forms and drawings are parsed into structured text first.⁴ Keyword and vector search are combined, and a knowledge graph is added where questions span a whole collection rather than one document.⁵ Permissions are enforced in the store, through row-level or document-level security, before anything reaches the model.⁶
• Anomaly and trend detection. Statistical methods such as control charts and outlier models detect what is unusual. The model explains what was detected, in the reader’s language, labelled as advisory. Detection stays deterministic and testable; language models alone are weak detectors, and specialised methods beat them by 30% in benchmark tests.⁷
• Assistants and agentic workflows for operations and planning. Workflows with fixed steps where the steps are known, and agents only where they are not. Tools are connected through the Model Context Protocol, kept few and read-only by default. Actions run under the user’s identity, and anything that changes the state of the world waits for a person’s approval.⁸ Where an assistant needs memory, it is a separate store with rules for what is kept, scoped and forgotten.⁹
• Model training on your data. For a narrow, well-defined task, a compact model fine-tuned on your own examples can match much larger general models, on modest hardware.¹⁰ Facts stay in retrieval, because teaching a model facts by fine-tuning is slow and raises hallucination;¹¹ fine-tuning teaches form, tone and decision rules. Adapters are versioned like prompts.
• Serving and capacity. Open-weight models chosen for the task and the licence, sized for the memory, context length and concurrency the use actually needs. Quantised models keep 99% of full-precision accuracy on average, so a smaller GPU often suffices.¹² Ollama serves models where concurrency is moderate. Higher-throughput serving such as vLLM is used where many users work at once.¹³

Securing the model and what it touches

A language model follows instructions, and it cannot reliably tell instructions from data.¹⁴ That makes it a new kind of attack surface. The OWASP Top 10 for LLM applications ranks prompt injection first, supply chain third and data and model poisoning fourth, with vector stores, excessive agency and system-prompt leakage further down the list.¹⁵ Cloudtech designs against each of them.

• Prompt injection. Instructions hidden in a document, an email or a web page are read by the model later, when a user asks about something else. In 2025 a single crafted email made a widely used office assistant hand over data, with no click from the user.¹⁶ Forged chat-template tokens let injected text pose as the system or the user.¹⁷ No filter stops this reliably, so the design assumes the model can be turned.¹⁸ Everything retrieved is treated as data and stripped of reserved tokens, the serving hosts have no network path out, and the model’s output is handled as untrusted, with links and images rendered only from an allow-list. Because permissions are enforced in the store, an injected instruction cannot reach data its reader may not see.
• Poisoned models and data. Backdoors trained into a model survive safety training.¹⁹ About 250 planted documents were enough to backdoor models of every size tested.²⁰ Five planted texts per question in an index of millions steered retrieval 90% of the time.²¹ A model can even be benign at full precision and malicious once quantised, including in the GGUF files Ollama serves.²² Cloudtech takes models only from named publishers, pinned by version and hash, and runs a behavioural evaluation set on the exact file that will be served. The retrieval index and fine-tuning data take documents only from governed sources, with provenance recorded.
• Malicious model files. Weights in pickle format execute code when loaded. Almost all malicious models found on the public hub use it, and scanners miss most of the ways it can be abused.²³ Serving hosts load safetensors or GGUF files only, verified against a checksum before use and against the publisher’s signature where one exists.²⁴ Model files sit in a repository under change control, like database binaries.
• Tools and agents. A tool’s description can carry hidden instructions. On real MCP servers, poisoned descriptions compromised agents in up to 72.8% of attempts, and the models refused in under 3%.²⁵ Tool servers are allow-listed, their descriptions reviewed and pinned, and each request sees only the tools it needs.²⁶ Least privilege per tool, read-only database access by default and a person’s approval for high-impact actions follow published guidance for agents.²⁷ Budgets cap tokens, calls and cost per task.
• Leakage. Vector embeddings are not anonymised data: in one study 92% of short texts were recovered exactly from their vectors, so the vector store carries the same permissions as the records.²⁸ Models memorise training data, and EU regulators treat a model as anonymous only if personal data cannot be extracted from it, which decides what may be fine-tuned on.²⁹ System prompts are not secret, so nothing the model must not reveal is put in its context.³⁰
• Guard models and testing. Open-weight guard models screen inputs and outputs, including whether an answer is grounded in its sources.³¹ They reduce attacks, but adapted attacks get past them, so the deterministic controls above carry the guarantees.³² The evaluation set includes injection attempts and over-refusal cases, covers the whole deployed system rather than the model alone, and runs on every change of model, prompt or adapter.³³

A European standard for securing AI systems and the NCSC and CISA guidelines now set the baseline for every AI system.³⁴ The EU AI Act requires high-risk systems to withstand data poisoning, model poisoning, adversarial inputs and confidentiality attacks from December 2027.³⁵ Cloudtech builds to them now.

What you get

• A documented use case with its measure of success and the result against it.
• Models running inside your network, on hardware you control, with no external AI service receiving a copy of your data.
• Permission-aware retrieval and role-based access, enforced outside the model.
• Structured, checkable output with evidence and confidence, shown alongside its input.
• A model supply chain you can audit: publisher, version, hash and licence recorded for every model, prompt and adapter, and an audit log of runs.
• A threat model for the integration, mapped to the OWASP Top 10 for LLM applications, and an evaluation set that includes injection attempts.
• Capacity sizing for the GPU hardware, measured on the real workload.
• Clear roles under the EU AI Act. The Act distinguishes the provider of an AI system from its deployer, and each project documents which party is which.

What we do not claim

Open-weight models are not open source unless their licence says so. On-premises inference does not by itself make a system compliant with anything. No model is free of errors, no prompt is immune to manipulation, and no guardrail stops every attack: in a 2025 public red-teaming competition, nearly all agents broke policy within 10 to 100 attempts, and attacks that worked on one model worked on others.³⁶ That is why the controls described here sit outside the model and assume it will, at some point, be fooled.