Every vendor selling software right now claims their product is AI-powered — and almost none of them mean the same thing by it.
For IT directors doing vendor due diligence, this is not a minor semantic problem. It is a procurement risk. When a contract is signed on the assumption that a platform runs genuine machine learning inference and it turns out to be a rules engine with a chatbot interface bolted on, the organization has paid enterprise prices for commodity functionality. The gap between ai powered software that actually runs models and software that merely invokes an API owned by someone else is enormous — in terms of cost structure, data exposure, auditability, and long-term control.
Here is the framework for telling the difference before you sign.
The Six-Level AI Implementation Spectrum
Not all AI claims are lies. They exist on a spectrum, and understanding where a vendor sits on that spectrum tells you almost everything about the real value and real risk you are buying.
Level 1 — Rule-based automation with AI branding. Conditional logic, decision trees, and keyword matching dressed up in AI language. No model is involved. This is the most common form of AI-washing.
Level 2 — Third-party API calls. The product calls OpenAI, Anthropic, or another foundation model provider. The vendor wrote a wrapper, not an AI system. Your data leaves your environment on every inference call, and your SLA is only as strong as that API provider’s uptime.
Level 3 — Pre-trained model embedding. A model trained elsewhere is embedded into the product. It works at deployment time but does not adapt to your data. Performance is static and generalized, not specific to your domain.
Level 4 — Fine-tuned models. The vendor fine-tuned a base model on domain-specific data. This is legitimate differentiation, but the question is whether your data contributed to fine-tuning — and whether it will in the future.
Level 5 — Retrieval-augmented generation or on-premise inference. The system retrieves from your data at inference time, or runs model inference inside your infrastructure boundary. This is where real enterprise AI starts. Data governance becomes tractable.
Level 6 — Full enterprise AI infrastructure. Model selection, deployment, access control, data routing, and audit logging are all under the organization’s control. This is what regulated industries require. It is also what most vendors are not actually selling, regardless of what their marketing says.
When a vendor says their product is ai powered software, your first question should be: which level? If they cannot answer, that is your answer.
The Six-Question Test Battery
Vendor conversations are structured to avoid this kind of precision. Sales cycles reward confident generalities. The following questions are designed to force specificity — and to make the gaps in a vendor’s actual AI implementation visible before the contract stage.
1. Where does inference run? On your infrastructure, on the vendor’s cloud, or on a third-party model provider’s API? This question alone eliminates a significant portion of AI-washing claims.
2. What happens to prompt data after inference? Is it logged? Is it used for model training? Is it transmitted outside your data residency requirements? A vendor that cannot answer this precisely does not have control over their own data pipeline.
3. Can the model be swapped? If a better model becomes available, or if your organization’s requirements change, can you change the underlying model without re-implementing the integration? Model lock-in is a real and underappreciated risk.
4. What is the audit trail? Can the system tell you which model version produced a specific output, on what date, with what inputs? In regulated environments — financial services, healthcare, government — this is not a nice-to-have.
5. Who controls access to the AI layer? Can your identity provider enforce role-based access to specific models or capabilities? Or is AI access a flat on/off permission at the application level?
6. What is the failure mode? When the AI component fails or produces a harmful output, how is that detected, contained, and remediated? A vendor with no answer to this question has not run ai powered software at enterprise scale.
These questions will not make you popular in vendor meetings. They will, however, tell you in thirty minutes what a six-month pilot might take a year to reveal.
Deployment Architecture as the Enterprise Buyer’s Test
The single most reliable signal of genuine enterprise AI capability is deployment architecture. Not a demo. Not a reference call. The actual architecture diagram, with data flows, model hosting locations, and access control layers labeled.
Vendors selling real ai powered software for enterprise deployment can produce this documentation because they have had to answer hard questions from security teams and compliance officers before. Vendors selling AI-washed products cannot produce it — or they produce something vague enough to be meaningless — because the architecture does not support the scrutiny.
What legitimate enterprise AI infrastructure looks like in practice: models running inside your VPC or on-premise environment, not phoning home; inference requests that never traverse a vendor’s network; access control integrated with your existing IAM; full logging of model inputs and outputs to your own SIEM; and the ability to update, replace, or turn off the model without vendor involvement.
This is the standard Peridot was built to meet. It runs inside your infrastructure, not ours. When an enterprise IT director looks at the Peridot architecture diagram, there are no calls to external model APIs by default, no vendor-controlled data pipelines, and no black boxes between the access control layer and the inference layer. That is not a differentiator in the marketing sense — it is what enterprise AI deployment actually requires.
The broader market has not caught up to this. Most vendors are still selling Level 2 and Level 3 implementations at Level 6 prices, and doing so by relying on the fact that most buyers do not yet have a framework for telling the difference.
The Decision You Have to Live With
The organizations that will get durable value from ai powered software are not the ones that move fastest. They are the ones that bought infrastructure they actually control, with data governance they can actually enforce, from vendors who could actually answer the hard questions.
Peridot exists for the IT director who looked at the vendor landscape, saw a lot of confident presentations with very little architectural substance, and decided that control matters more than speed-to-demo.
The AI vendors who cannot answer the six questions are not hiding something accidentally. They built their products for a buyer who does not ask. That buyer exists — but it is not you, and it is not the organization you are responsible for protecting.
Buy the architecture, not the demo. You will defend that decision for years.