AI infrastructure has become one of the fastest-growing lines in many technology budgets. GPUs are expensive, whether rented by the hour in the cloud or bought for a data center, and demand for them often runs ahead of supply. Finance leaders want to know what they are getting for the money. Engineering leaders often answer with utilization charts.

Utilization matters, but it answers the wrong question. A GPU running at full load on retries, abandoned requests and outputs no one uses is busy, not productive. This post sets out a better way to measure.

Three levels of measurement

Level 1: resource metrics

These are the familiar ones: GPU utilization, memory use, hours provisioned and hours used. They tell you whether you are paying for idle capacity. They are essential for capacity planning, and they are where most teams stop.

Level 2: cost per token

The next step is to divide infrastructure cost by tokens processed, separately for input and output. This lets you compare self-hosted models with API pricing, and compare models and configurations with each other. It is a real improvement, but it still counts every token as equally valuable.

Level 3: cost per useful outcome

The measure that matters is what it costs to produce a result that was actually used. That requires two refinements.

First, count useful tokens: tokens that contributed to an accepted result. Exclude tokens spent on failed requests, timeouts, retries, discarded drafts, responses a person rejected and outputs that failed verification. In agentic systems, also look closely at the long chains of intermediate reasoning and tool calls that lead nowhere.

Second, tie cost to a unit of business work: a support ticket resolved, a contract reviewed, a code change merged and verified, an alarm correctly triaged. Cost per outcome is the number a CFO can compare with the cost of doing the same work another way.

An illustrative example

The following figures are hypothetical and for illustration only. Imagine a document-review service where infrastructure costs a fixed amount per month and the team reports high GPU utilization. On closer inspection:

• A meaningful share of requests are retries caused by timeouts under peak load.
• Many documents are processed twice because two upstream systems submit them.
• Some outputs fail a validation check and are discarded, then regenerated.
• The model used is far larger than the task needs for most document types.

None of these problems appear in a utilization chart. All of them appear immediately when you measure cost per accepted review. Fixing them can reduce cost per outcome substantially without buying a single additional GPU.

Where the waste usually hides

• Oversized models. A large general model handling tasks that a smaller or fine-tuned model would do as well. Routing requests by difficulty is often the single largest saving.
• Poor batching and scheduling. Serving software configured for latency when the workload is batch, or the reverse.
• Idle reservations. Capacity reserved for peak load and left idle the rest of the time, without workloads that can use the slack.
• Long contexts by default. Sending entire documents or conversation histories when a smaller, retrieved slice would do.
• Duplicate work. No caching for repeated prompts, embeddings or retrieval results.
• Failed agent runs. Agents that loop, retry or explore far more than they need to before succeeding or giving up.

Building the measurement

1. Tag every request. Record the team, application, model, workload type and environment for each inference call. Without attribution, cost cannot be managed.
2. Record the outcome. Capture whether each result was accepted, rejected, retried or verified. This usually requires a signal from the application, not only from the model server.
3. Allocate infrastructure cost. Split GPU, memory, storage and network cost across requests in proportion to what they consumed.
4. Report at all three levels. Resource metrics for operations, cost per token for engineering, cost per outcome for business owners and finance.
5. Set targets per workload. A real-time voice agent and an overnight batch job have very different acceptable costs per outcome.

Optimizing with care

Once you can see cost per outcome, it is tempting to cut aggressively. Two cautions apply.

First, keep quality in the same view. A cheaper configuration that lowers the acceptance rate may raise cost per outcome, not lower it. Every optimization should be checked against your evaluation suite before it reaches production.

Second, make changes reversible. Infrastructure changes such as model swaps, quantization, batching settings and node pool changes should be applied one at a time, measured against a baseline, and rolled back automatically if quality or latency drops below target.

Why this matters beyond cost

Cost per useful outcome also improves planning. When you know what a unit of work costs today, you can forecast what a new workload or a growth in volume will cost tomorrow, and decide where to place it: on a frontier API, on private models in your cloud, or on owned hardware.

Our product TuQuant Prizm gives AI infrastructure teams this view, connecting GPU spend to the workloads and outcomes it supports, and helping them act on what they find. If AI infrastructure is a growing share of your budget, talk to us about measuring it in terms your business recognizes.

Originally published at tuquant.si.

Most AI pilots are judged on impressions. A team runs a few dozen examples, the outputs look reasonable, a demo goes well, and the project moves forward. With agents, that approach breaks down quickly. An agent takes many steps, calls tools, and changes things. A fluent final message can hide a wrong database update, a skipped check or a task that was never finished.

If you are going to trust an agent with real work, you need evaluation that checks outcomes. This post describes how we approach it.

Evaluate the outcome, not the transcript

The most important shift is from judging what an agent said to judging what it did. For each task, define the end state that counts as success, and check that state directly.

• A coding agent succeeds when the change compiles, the relevant tests pass and no unrelated tests break.
• A data agent succeeds when the query returns the correct rows, checked against a known answer.
• A document agent succeeds when each extracted field matches the source, and each claim cites the passage it came from.
• An operations agent succeeds when the incident is resolved and the metrics that triggered it return to normal.

These checks are ground-truth verifiers: deterministic programs that inspect the result and return pass or fail, with a reason. They are not perfect, but they are repeatable, cheap to run and hard to talk your way past.

When ground truth is hard to get

Some outcomes cannot be checked by a program. Is this summary faithful? Is this customer reply appropriate in tone? For these, teams often use another model as a judge. That is reasonable, with three conditions:

1. Calibrate the judge against people. Have domain experts grade a sample, and measure how often the model judge agrees. If agreement is low, the judge is not ready.
2. Use narrow rubrics. "Rate quality from one to ten" invites noise. "Does the reply contain any commitment not present in the policy document?" is far more reliable.
3. Keep people in the loop for drift. Re-check a sample of judge decisions on a schedule, because both the judged model and the judge can change.

Where you can, break a fuzzy outcome into checkable parts. Faithfulness, for example, can be partly verified by confirming that every cited passage exists and supports the claim attached to it.

Build an evaluation harness

An evaluation harness is the system that runs your agent against a test set and records the results. A useful one has these properties:

• Realistic tasks. Drawn from real work, with sensitive details removed, and covering common cases, edge cases and known failure modes.
• Reproducible environments. Each run starts from the same state: the same files, records and tool responses. Sandboxed copies of real systems work well.
• Full traces. Every step, tool call, input and output is recorded, so failures can be diagnosed rather than guessed at.
• Multiple runs. Agents are not fully deterministic. Run each task several times and report the pass rate, not a single result.
• Cost and time. Record tokens, tool calls and elapsed time per task. An agent that succeeds slowly and expensively may not be worth deploying.
• Safety cases. Include tasks with injected instructions, missing permissions and ambiguous requests, and check that the agent refuses, escalates or asks rather than guessing.

Gate releases on results

Evaluation only protects you if it is wired into how changes ship. Every change to the model, the prompts, the tools or the retrieval data can change agent behavior. Treat each one like a code change:

• Run the evaluation suite automatically before promotion.
• Set thresholds per task category, and block promotion when a category drops below its threshold.
• Require a named person to approve any exception, with the reason recorded.
• Keep the history, so you can see whether quality is trending up or down over time.

This is a regression gate. It turns evaluation from a report people may read into a control that acts on its own.

Close the loop from production

No test set anticipates everything. Production will surface failures you did not imagine. The discipline that matters most is simple: every confirmed production failure becomes a new test case. Over time, your evaluation suite becomes a record of everything that has gone wrong, and a guarantee that it will not go wrong the same way twice without someone noticing.

In production, the same verifiers can run continuously on a sample of live work. When a verifier fails, the system can hold the result for review, route it to a person, or roll back to a previous configuration, depending on the stakes.

Report what matters to the business

Technical pass rates are necessary, but they are not what leaders need. Translate results into terms tied to the workload: tickets resolved without rework, documents processed without a correction, incidents closed within target time, cost per completed task. These are the measures that justify widening an agent's scope, or narrowing it.

A starting checklist

1. Write down the success state for each task the agent performs.
2. Build a verifier for every success state that can be checked by a program.
3. Assemble a test set of at least a few dozen realistic tasks, and grow it.
4. Calibrate any model-based judge against expert grading.
5. Wire the suite into your release pipeline as a blocking gate.
6. Route production failures back into the test set.

Verifiable evaluation is how we build our own products, including TuQuant Medha for the software lifecycle, and how we build agents for clients through our agentic AI development practice. If you want a second opinion on how your agents are measured, contact us.

Originally published at tuquant.si.

Over the past decade, software teams learned to ask where their code came from. Dependency scanning, signed builds and software bills of materials became standard practice after a series of high-profile supply-chain compromises. AI systems need the same discipline, and they add new kinds of artifacts that most existing tools were not built to track.

The OWASP Top 10 for LLM Applications lists supply chain risk as its own category, and data and model poisoning as another. MITRE ATLAS documents real-world techniques for compromising machine learning supply chains. This post sets out a practical approach for security and AI teams working together.

What is in an AI supply chain

A deployed AI system typically depends on:

• Base model weights, often downloaded from a public model hub or provided by a vendor.
• Adapters and fine-tuned weights, produced in-house or by a partner.
• Training and fine-tuning datasets, from internal systems, licensed sources or public collections.
• Retrieval corpora and embeddings, which shape what the model sees at run time.
• Tokenizers, configuration files and prompt templates, which change behavior as much as weights do.
• Serving software, including inference servers, GPU drivers and the libraries beneath them.
• Third-party tools and plugins that agents can call.

Each one is a place where something can be altered, substituted or poisoned.

Risk 1: weights that execute code

Some common model file formats are built on Python's pickle serialization, which can execute arbitrary code when a file is loaded. A model file downloaded from an untrusted source can therefore behave like an untrusted executable. This is not theoretical; security researchers have repeatedly found malicious model files on public hubs.

What to do:

• Prefer formats designed to store tensors without executable content, such as safetensors.
• Scan model files before they enter your environment, and load untrusted files only in isolated sandboxes.
• Maintain an internal model registry. Production systems pull only from that registry, never directly from the internet.

Risk 2: poisoned or tampered models

A model can be modified to behave normally on most inputs and differently on specific triggers. Such backdoors are hard to detect by inspection alone. A model that claims to be a known release may also simply be a different file.

What to do:

• Verify cryptographic hashes against values published by the original source.
• Sign models that you produce, and verify signatures at deployment. Open tooling from the Sigstore project and similar efforts supports signing ML artifacts.
• Evaluate every model on your own test sets before promotion, including adversarial and trigger-search tests, and compare behavior against a known-good baseline.

Risk 3: data you cannot account for

Training and fine-tuning data shape model behavior directly. Poisoned examples can introduce bias, backdoors or quiet errors. Data with unclear licensing or consent can create legal exposure. Data that contains secrets or personal information can leak through the model later.

What to do:

• Record lineage for every dataset: source, collection date, license, transformations applied and who approved its use.
• Version datasets the way you version code, so any model can be traced to the exact data that produced it.
• Scan training data for secrets and personal information before use, and document the result.
• Apply the same controls to retrieval corpora. An attacker who can add a document to your knowledge base can influence answers without touching the model.

Risk 4: the serving stack

Inference servers, model runtimes and GPU software are software, with ordinary vulnerabilities. They often run with broad permissions and access to sensitive data.

What to do:

• Include the serving stack in standard vulnerability management, with container scanning and patch timelines.
• Run model servers with least privilege and network isolation.
• Pin versions and build from verified sources, following practices from the NIST Secure Software Development Framework (SP 800-218) and its generative AI community profile (SP 800-218A).

An AI bill of materials

A software bill of materials lists the components in an application. An AI bill of materials extends that list to models and data. Both leading SBOM standards now cover this ground: CycloneDX includes support for machine learning components, and SPDX 3.0 adds AI and dataset profiles.

A useful AI bill of materials records, for each deployed system:

• The base model, its source, version and hash.
• Any adapters or fine-tuned weights, with the datasets and configuration used to produce them.
• Retrieval sources and their update process.
• Tokenizer, prompt templates and system configuration versions.
• Serving software and its dependencies.
• Evaluation results that justified promotion to production.

When a vulnerability is disclosed in a model family, a dataset or a library, the bill of materials tells you in minutes which systems are affected.

Putting it into practice

You do not need to solve everything at once. A sensible order of work:

1. Stand up an internal model registry and route all production pulls through it.
2. Require hash verification and a safe serialization format for every model entering the registry.
3. Add dataset lineage records for anything used in fine-tuning.
4. Generate an AI bill of materials for each production system, and store it with the deployment record.
5. Add signing and signature verification to your model promotion pipeline.
6. Extend red-team and evaluation work to cover poisoning and backdoor scenarios.

The principle underneath

You cannot secure what you cannot name. Supply-chain security for AI is mostly about knowing, at any moment, exactly which model, data and code are running, where each came from and who approved it. That knowledge is also what auditors and regulators increasingly expect.

Our AI governance and security practice helps teams build model registries, AI bills of materials and verification pipelines that fit existing DevSecOps tooling. Get in touch to review your current model supply chain.

Originally published at tuquant.si.

Few decisions in enterprise AI generate as much debate as this one: should we build or fine-tune a model of our own, or use a frontier model through an API? The debate often goes in circles because it is framed as a single choice for the whole organization. In practice it is a series of choices, one per workload, and the right answer for your contract review assistant may be wrong for your customer service voice agent.

This post offers a framework we use with clients. It is deliberately simple. The aim is to make the trade-offs explicit so the decision can be explained and revisited.

First, define the options clearly

"Custom LLM" covers several distinct approaches, and they differ a great deal in cost and effort:

• Frontier API. You call a hosted model from a major provider. You control prompts, retrieval and tools, but not the model or where it runs.
• Frontier model in your cloud tenancy. Some providers offer their models through cloud platforms with regional hosting and enterprise data terms. Control improves, but the model is still not yours.
• Open-weight model, self-hosted. You run a publicly released model in your VPC, data center or sovereign environment. You control the runtime and the data path.
• Fine-tuned model. You adapt an open-weight model to your domain, tone, formats or tasks using your own data.
• Model trained from scratch. Rarely justified outside a few organizations with very large, distinctive data and long time horizons.

Most real decisions sit between the first four.

The six questions

1. Where must the data and the model reside?

Start here, because it often settles the matter. If a workload handles classified information, regulated health records, export-controlled technical data or material bound by contractual residency terms, your options may be limited to models you host yourself. Ask your legal, privacy and security teams for the actual constraint, in writing, rather than working from assumptions in either direction.

2. What quality bar does the task require, and can a general model meet it?

Build a small evaluation set from real examples, with expected outputs that a domain expert has checked. Run the strongest general model you are permitted to use, with good prompts and retrieval. If it clears the bar, you may not need anything custom. If it misses in consistent ways, such as a specialized vocabulary, a strict output format or domain reasoning it does not know, fine-tuning may close the gap.

3. What will it cost at your expected volume?

API pricing is easy to start with and scales linearly with use. Self-hosting has a high fixed cost in GPUs, engineering and operations, but a lower marginal cost per request once utilization is high. The crossover point depends on volume, model size, latency targets and how well you keep hardware busy. Model your own numbers. A smaller fine-tuned model that does one task well can be far cheaper to serve than a large general model, but only if the volume justifies the setup.

4. What latency and availability do you need?

Voice agents, real-time operations and edge deployments often need low, predictable latency and must keep working when an external service is degraded. Self-hosted models give you more control over both. Batch workloads, such as overnight document processing, are far more tolerant.

5. How much control do you need over change?

Hosted models are updated and retired on the provider's schedule. For many tasks that is fine. For regulated workloads where a model change may require revalidation, or where outputs must stay stable for audit, owning the model version is a real advantage. If you use an API, pin model versions where the provider allows it, and keep your evaluation suite ready to rerun when a version changes.

6. Can you operate it?

A custom model is a product, not a project. Someone must own its training data, evaluation, serving infrastructure, security patching, monitoring and retraining. If you do not have, or cannot build or buy, that capability, the theoretical benefits of a custom model will not arrive.

A simple decision path

1. If residency or control requirements rule out external hosting, go to self-hosted open-weight models, and fine-tune if evaluation shows a gap.
2. If not, try the strongest permitted general model with good retrieval and prompts. If it meets the quality bar at an acceptable cost, use it.
3. If it meets quality but not cost or latency at your volume, evaluate a smaller self-hosted or fine-tuned model for that specific task.
4. If it misses quality in consistent, domain-specific ways, run a fine-tuning experiment and compare against the same evaluation set.
5. Revisit the decision when volume, regulation or available models change.

Common mistakes

• Fine-tuning to add knowledge. Fine-tuning is better at teaching format, style and task behavior than at teaching facts. For facts that change, retrieval is usually the better tool.
• Skipping the baseline. Without a measured baseline from a general model, you cannot show that a custom model is better.
• Underestimating data work. Most of the effort in a fine-tuning project is collecting, cleaning, labeling and reviewing examples.
• Treating it as a one-time decision. Open-weight models and hosted offerings both improve quickly. A choice that was right a year ago may not be right today.

The likely answer: a portfolio

Most enterprises we speak with arrive at a portfolio. Sensitive or high-volume tasks run on private models they control. General reasoning and low-volume tasks use frontier models where policy allows. A routing layer decides which model handles each request, based on data classification, cost and quality targets, and records the decision.

The value of the framework is that each placement has a written reason. When a regulator, an auditor or your own board asks why a workload runs where it does, you have an answer.

We help organizations make and carry out these decisions, from evaluation design to private deployment in your cloud, VPC or on-premises environment. See our sovereign and on-premises AI services, or contact us to talk through a specific workload.

Originally published at tuquant.si.

Prompt injection sits at the top of the OWASP Top 10 for LLM Applications for a reason. Large language models do not reliably separate instructions from data. Any text that reaches the model, whether it comes from a person, a web page, an email, a PDF or a tool response, can try to change what the model does next.

With a chat assistant, a successful injection usually produces a bad answer. With an agent that can call tools, it can produce a bad action: data sent to the wrong place, a record changed, a payment queued, a configuration altered. The OWASP list names this second risk directly as excessive agency.

The honest position is that there is no complete technical fix for prompt injection today. Classifiers and prompt hardening reduce the rate of success, but they do not bring it to zero. The defensible strategy is defense in depth: assume some injected instructions will reach the model, and design the system so that when they do, the damage is small, visible and reversible.

Here is the checklist we use when we review an agentic system.

Layer 1: trust boundaries for input

• Classify every input source by trust level. Instructions from your own system prompt and configuration are trusted. Content from a person in your organization is partly trusted. Content from the internet, inbound email, uploaded files and third-party APIs is untrusted.
• Mark untrusted content as data. Wrap it in clear delimiters and tell the model it is material to analyze, not instructions to follow. This does not stop injection on its own, but it raises the bar.
• Watch for indirect injection. The most damaging attacks often arrive through retrieval: a poisoned document in a knowledge base, a hidden instruction in a web page, text in an image or a file's metadata.
• Screen inputs with a dedicated detector. Use a classifier or rules to flag likely injection attempts, and route flagged content to a lower-privilege path rather than silently dropping it.

Layer 2: least privilege for tools

• Give each agent the smallest tool set that does the job. An agent that summarizes tickets does not need to close them.
• Scope credentials per agent and per task. Use short-lived tokens tied to the agent's identity, never a shared service account with broad rights.
• Separate read from write. Many useful agents only need read access. Where write access is required, scope it to specific records or fields.
• Constrain tool parameters. If a tool sends email, restrict recipients to approved domains. If it queries a database, restrict it to named views. Enforce these limits in the tool, not in the prompt.
• Isolate privileged reasoning from untrusted content. One useful pattern is to let a low-privilege model read untrusted material and return structured data, while a separate step with tool access never sees the raw text.

Layer 3: validate before anything executes

• Check every tool call against a schema and a policy. Reject calls with unexpected parameters, out-of-scope targets or unusual volume.
• Treat model output as untrusted too. OWASP lists improper output handling as its own risk. Never pass model output directly to a shell, a SQL engine, a browser or a template without encoding and validation.
• Block data exfiltration paths. Watch for output that embeds sensitive data in URLs, image links or markdown that a client will render and fetch.
• Rate-limit actions. A sudden burst of tool calls is a signal worth stopping on, whether the cause is an attack or a loop.

Layer 4: people in the loop where it counts

• Define which actions are consequential. Moving money, deleting data, changing access, contacting customers and changing production systems are common examples.
• Require explicit approval for those actions. Show the approver what the agent intends to do, why, and which inputs drove the decision.
• Design approval screens to resist fatigue. If approvers see hundreds of routine requests a day, they will stop reading. Keep approvals for actions that deserve them.
• Prefer reversible actions. Drafts before sends, staged changes before commits, soft deletes before hard deletes.

Layer 5: observe, record and respond

• Log the full chain. Record the inputs the agent saw, the tool calls it proposed, the policy decisions made, the approvals given and the results returned.
• Make logs tamper-evident. An attacker who can influence an agent may also try to influence its records.
• Feed agent telemetry into your security operations. Agent actions should appear alongside other identity and access events, with alerts for unusual patterns.
• Write an incident playbook for agents. Know how to suspend an agent, revoke its credentials and review its recent actions within minutes.

Layer 6: test like an attacker

• Run red-team exercises before launch and after major changes. Include direct and indirect injection, tool misuse and data exfiltration attempts.
• Keep a regression suite of known attacks. Every new attack you discover becomes a test case that runs on every model, prompt or tool change.
• Use shared threat knowledge. MITRE ATLAS catalogs adversary tactics and techniques against AI systems, and is a useful map when planning test coverage.

A quick self-assessment

If you can answer yes to these five questions, your agent is in better shape than most:

1. If the model followed an injected instruction, could the worst resulting action be undone?
2. Are tool permissions enforced outside the model, in code or policy?
3. Does every consequential action require a named person to approve it?
4. Could you reconstruct, from logs alone, why the agent did what it did last Tuesday?
5. Do known attacks run as automated tests before every release?

Where we can help

We design and review agentic systems with these layers built in, and our AI governance and security practice runs structured assessments and red-team exercises against existing deployments. If you are preparing an agent for production, talk to us before it gets write access to anything that matters.

Originally published at tuquant.si.

We describe TuQuant as a superintelligence company, and our tagline is Superintelligence, Engineered. Both phrases deserve an explanation, because the first word carries a great deal of noise and the second is easy to skip past. This post sets out what we mean, what we do not mean, and why the distinction matters to a CISO, a CIO or a head of AI deciding where to place real workloads.

What we do not mean

We do not mean a single model that knows everything, decides everything and answers to no one. That framing is common in public conversation, and it is a poor fit for an enterprise. Organizations do not buy intelligence in the abstract. They buy the ability to get specific work done, at a known level of quality, under rules they can explain to a regulator, an auditor or a board.

We also do not mean a claim about benchmarks. Leaderboard scores move every few months, and a high score on a public test tells you little about how a system will behave against your data, your tools and your edge cases.

What we do mean

For us, superintelligence is a direction of travel: systems that can perform an increasing share of expert work, across more domains, faster and more consistently than a team could alone. The word engineered is the part that makes that direction safe to follow. It commits us to three properties.

1. Bounded capability

Every system we ship has a defined scope of action. It knows which data it may read, which tools it may call, which decisions it may make on its own and which it must hand to a person. A model may be capable of far more than its scope allows. That gap is deliberate. In an enterprise, the useful question is not "what can this model do" but "what is this system permitted to do, and how do we know it stayed inside those limits."

Bounding capability is also how you scale it. When the scope is explicit, you can widen it one step at a time, with evidence at each step, rather than granting broad access and hoping nothing goes wrong.

2. Governed action

Governance is often treated as paperwork that sits next to a system. We treat it as part of the system. That means access controls that apply to agents as well as people, a clear line between recommendation and action, human approval where the stakes call for it, and a record of what happened that a reviewer can read months later.

When governance is designed in, it stops being a brake. Teams move faster because the guardrails are known in advance, and security and risk functions can say yes to a deployment without negotiating every detail from scratch.

3. Measured outcomes

Intelligence that cannot be measured cannot be managed. For each workload we ask a plain question: what outcome should change, and how will we know it changed? For a software team, that might be lead time from ticket to verified release. For a contracts team, it might be the share of documents where every extracted clause traces back to its source. For an infrastructure team, it might be what each useful result costs in compute.

We prefer outcomes that can be verified against ground truth over scores produced by another model's opinion. Where ground truth is hard to get, we say so, and we design the evaluation around that limit rather than hiding it.

Why this matters now

Agentic systems have changed the risk picture. A chat assistant that drafts text has a narrow blast radius. An agent that reads email, queries databases, opens tickets and changes configuration has a much wider one. The same capability that makes agents valuable is what makes them worth attacking, and what makes their mistakes expensive.

That shift raises the bar for three groups:

• Security leaders need AI systems to fit inside existing identity, logging and incident response practices, and they need new controls for new attack surfaces such as prompt injection and model supply chains.
• Technology leaders need to decide what runs on frontier APIs, what runs on private or custom models, and what runs in their own cloud, data center or sovereign environment.
• Heads of AI need evaluation practices that hold up when a system moves from a pilot with friendly inputs to production with real ones.

How it shows up in our work

The engineering commitment shapes each part of what we offer:

• Enterprise AI products. Our product line covers software delivery, voice, communications, documents and audit, energy, content, telecom operations, AI infrastructure cost and defense. Each product is scoped to a domain and judged by outcomes in that domain.
• Custom, private and sovereign LLMs. We help you decide when a model of your own is worth it, and deploy it in your cloud, VPC or on-premises environment when it is.
• AI and model security. We secure the model, the data around it and the agents that act on its output, using public frameworks such as the NIST AI Risk Management Framework, the OWASP Top 10 for LLM Applications and MITRE ATLAS as a shared vocabulary.
• Agentic systems. We build agents that act within explicit limits and report what they did in terms a reviewer can check.
• Solutions and consulting. We work alongside your teams on strategy, architecture and rollout, so the capability stays with you after we leave.

Questions worth asking any AI vendor

Whether or not you work with us, these questions separate engineered systems from demonstrations:

1. What exactly is this system allowed to do, and where is that written down?
2. What happens when it is uncertain, or when its input is hostile?
3. Which actions require a person to approve them, and can that threshold be changed without a code release?
4. How is quality measured, against what ground truth, and how often?
5. What does the audit record contain, and who can read it?
6. Where do the model, the data and the logs physically reside?

If the answers are vague, the system is not ready for work that matters.

The short version

Superintelligence, for an enterprise, is not a single leap. It is a steady widening of what systems can do for you, earned one bounded, governed and measured step at a time. That is the work we have chosen. If you are planning where AI should act inside your organization, we would be glad to compare notes, or you can start with our consulting practice.

Originally published at tuquant.si.