DEV Community: Deb_Ghosh_Analsyt Layer

What Technology Buyers Ask AI Assistants Before Agreeing to Meet a Vendor

Deb_Ghosh_Analsyt Layer — Fri, 11 Sep 2026 08:41:54 +0000

Technology buyers increasingly use AI assistants to research vendors before they ever fill out a form, reply to an email, or agree to a sales meeting.
The questions are rarely broad category queries.
They're specific:

Will this work with Salesforce and SAP?
How difficult is migration?
What will it actually cost at 500 users?
Who are the serious alternatives?
What happens to our data if we leave?
Has a company like ours actually deployed it? That creates a new problem for vendors. The shortlist can be formed before the vendor knows there is a deal. This article lists 20 questions that repeatedly appear in buyer conversations, explains two ways to discover the questions relevant to your own category, and gives you a process for finding the six questions most worth winning.

The 20 questions buyers are asking
The easiest way to understand the shift is to stop thinking in terms of categories and start thinking in terms of purchase decisions.
A buyer doesn't necessarily ask:

"What's the best data platform?"
They ask:
"Does this data platform work with the systems we already run?"
That difference matters.

Fit — Will this work where I already am?
Does this tool connect properly to Salesforce and SAP without custom work?
How long does a typical rollout take for a company with 3,000 employees?
Can it handle 10 million records a day without the price jumping?
Which tools in this category suit a mid-sized manufacturer rather than a large bank?

What has to be in place before we start — clean data, a dedicated administrator, anything else?
These questions are really about implementation risk.
The buyer isn't asking whether the product has a feature.
They're asking whether their environment will work with it.

Risk — What goes wrong?
What do customers complain about most with this vendor?
Why do companies leave this vendor after two or three years?
How hard is it to move our data out if we change our minds?
Is this vendor stable enough to still be here in five years?
Who owns the data, and what happens to it when the contract ends?
This is where AI-assisted research becomes particularly interesting.
Vendor websites are naturally optimized to explain strengths.
Buyers want to understand failure modes.
Those are not the same information problem.

Cost — What will this really cost?
What does this actually cost for a company with 500 users?
Which costs show up later that are not in the first quote — training, support, extra modules?
Is the more expensive option worth the difference over the cheaper one?
How long before this pays for itself in a normal deployment?
Notice that none of these questions is simply "What is your price?"
The buyer wants the economic outcome, not just the list price.

Proof — Has anyone like me done this?
Which companies in manufacturing have deployed this successfully?
Has any company our size done this, or only large enterprises?
What results have real customers reported, not the vendor's own claims?
Who are the serious alternatives, including ones the vendor would not mention?

This is the point where being "well known" and being "credible for this buyer" become two different things.
A vendor can have hundreds of enterprise customers and still be a poor fit for a specific industry, company size, architecture, or use case.

Process — What do I do next?
What should we ask in a first meeting to find out quickly whether this is a fit?
How do we compare three vendors fairly when each measures things differently?
These are particularly important because they move the AI assistant from researcher to decision-support tool.
The buyer isn't just asking which vendor is good.
They're asking how to run the buying process.

The pattern behind all 20 questions
Almost none of these questions are answered cleanly on a vendor's homepage.
Vendor websites answer:
"What do we do?"
Buyers are asking:
"What happens to me?"
That's the fundamental gap.
And it creates two different ways for vendors to understand what buyers are actually asking.
Two ways to find your own list
There are two useful methods.
They don't produce the same information.

The strongest approach is to use both.

What machine-based tools do well
Platforms such as Profound can query AI assistants at scale and track which sources get used in their answers.
That creates something valuable:
a measurable baseline.
Instead of asking, "Does AI know about us?", you can track questions such as:

How often is our company mentioned?
Which competitors appear?
Which sources are being cited?
Which pages are influencing the answer?
What changes over time? For a company managing dozens or hundreds of buyer questions, doing this manually doesn't scale.

Machine-based discovery gives you breadth and repeatability.
If you want to know where you stand today, this is the fastest route.
What machine-based tools cannot see
There is an important limitation.

They can only observe questions that have already been asked and answered in some measurable environment.

They cannot see the question a buyer asks a colleague.
They cannot see the question a buyer thinks about but never types.
They cannot see the concern that makes someone quietly remove a vendor from the shortlist. And those questions can be the most commercially important ones. For example: "Would our security team actually approve this?" may never appear in public AI queries. But it can still determine whether a vendor gets to the next stage.

What buyer interviews add

This is where direct buyer research becomes useful.
A structured buyer conversation is not a product demo.
The researcher asks about the actual evaluation:

What triggered the purchase?
What did you compare?
What did you ask an AI assistant?
What almost disqualified a vendor?
What information was missing?
When did a vendor disappear from the shortlist?
What question did you wish someone had answered earlier? That produces something machine-based monitoring cannot: the language buyers actually use. It also surfaces questions that never became public queries.

Use both: machines for breadth, interviews for depth
The two approaches work best together.
Machine-based discovery tells you what the market is already answering.
Buyer interviews tell you what the market is still struggling to answer.
The intersection is where the most useful content opportunities usually appear.
That intersection is also where buyer intelligence becomes more valuable than simply tracking visibility, because the questions buyers ask reveal what they are actually trying to decide and where existing vendor information falls short. Analyst Layer combines technology intelligence with primary, field-grounded research to understand what buyers are comparing, what concerns shape their decisions, and where vendors need better evidence to influence the shortlist.

How to build your own list in five steps
You don't need a sophisticated system to start.

1. Write down 30 candidate questions
Take the five groups above:

Fit
Risk
Cost
Proof
Process Rewrite each question around your category, competitors, and the systems your buyers already use.

"Does this work with Salesforce and SAP?" is more useful than "Is this platform good?"
Make the questions specific enough that a buyer could actually use them during an evaluation.

2. Run each question through four AI assistants
Record:

which vendors are mentioned
which sources are cited
which companies appear repeatedly
what information is missing
the date of the query
Keep the date.
AI-generated answers change.
A position you observe today is not a permanent ranking.
3. Mark where you are absent
This is important.
Absence is the finding.
If buyers are asking a commercially important question and your company never appears in the answer, that is useful information.
Don't immediately interpret it as a content problem.
First determine why you're absent.
Maybe nobody has published the answer.
Maybe competitors have stronger evidence.
Maybe the assistant relies on third-party sources.
Maybe your existing content answers the wrong version of the question.

4. Test the list against real buyers
Take the questions to five recent buyers.
Ask:
"Which of these did you actually ask?"
Then ask:
"What did we miss?"
This is usually where the interesting information appears.
The questions buyers remember asking are often more specific than the questions a marketing team expects them to ask.
5. Pick the six worth winning
Don't try to own 100 questions.
Score each question on two dimensions:

Then prioritize the high-closeness, low-competition questions.
Those are the questions closest to an actual buying decision where relatively few strong sources currently exist.

What to do once you know the questions
Being named in an AI answer is the beginning.
It isn't the finish line.
A mention puts you on the shortlist.
It doesn't create a conversation.
The next question is:
Where does the buyer go from there?
This is where many vendors make the wrong move.
They turn every research question into a CTA for a sales meeting.
But the buyer may not be ready for that.
They may still be trying to understand the problem, compare options, or validate a decision they already have in mind.
In our work, one useful next step is an independent analyst conversation where the buyer can work through their own criteria without being pushed into a product pitch.
That kind of conversation also produces better intelligence for the vendor.
The buyer explains what they are actually trying to decide.
And that brings us back to the original problem.
The questions that determine the outcome are often not the questions vendors have answered anywhere.

The shift toward AI-assisted buyer research changes the visibility problem from simply being discoverable to being relevant at the exact moment a buyer is forming a shortlist. This analysis looks at that shift in detail, examining how buyers are using AI assistants to compare technology vendors before engaging sales and what companies can do to understand and influence the questions shaping those decisions.

Common questions about this method
How many questions should we track?
Start with 6–20.
Beyond that, most teams struggle to turn the findings into action.
The goal isn't to monitor everything.
It's to identify the questions closest to a purchase that are currently underserved.

How long before a new page shows up in AI answers?
Usually weeks, sometimes longer, and never guaranteed.
Treat any position as temporary.
Re-check important questions regularly rather than assuming that publishing once means the problem is solved.
Do we need software?
No.
The first pass can be done manually in a day.
Software becomes useful once you're tracking many questions repeatedly and need consistent measurement across assistants and time.
Is this the same as SEO?
No.
Traditional search optimization is largely about getting a page to rank for a search query.
This is about becoming a source that an AI assistant uses when it constructs an answer.

There is overlap in the underlying fundamentals — useful content, authority, accessibility, and evidence — but the target is different.
Who should own this inside a company?
Usually, whoever owns early pipeline should care about it.
It often gets pushed into product marketing because it looks like a content problem.

But the commercial outcome is bigger than content.
If a buyer forms a shortlist before talking to sales, then understanding what appears in that shortlist is ultimately a pipeline question.

The shift buyers have already made
The important change isn't that buyers are using AI assistants.
It's when they're using them.
The vendor used to enter the process relatively early.
A buyer had a problem, searched for vendors, visited websites, downloaded material, and eventually spoke to sales.
Now there is another layer before that.

The buyer can ask:
"Which three vendors should I consider?"
Then:
"Which one works best with our stack?"
Then:
"What do customers complain about?"
Then:
"What happens if we need to leave?"
All before a vendor receives a form submission.
That's why the most important AI visibility question for a technology company isn't:
"Does AI know who we are?"
It's:
"When a buyer asks the question that could determine whether we make the shortlist, what answer does the AI give — and are we part of it?"

Finding Personal Data Across Old Systems Before a Data Law Deadline

Deb_Ghosh_Analsyt Layer — Fri, 11 Sep 2026 07:38:05 +0000

A new data protection law does not care how old your systems are.
It asks a much simpler question:

Where does personal data live across every system the company has ever used — and can you prove it?
Most engineering and security teams can answer that question for the systems they actively manage today.

They know where the CRM lives. They know which cloud storage contains HR records. They can usually identify the databases behind current applications.

The harder problem is everything that came before.
Old file shares. Retired databases. Email archives. Backups. Spreadsheets sitting on departmental drives. Systems that were migrated years ago but never completely decommissioned.
And then there is the data that isn't inside your environment at all: personal data handed to contractors, processors, and other third parties.
That is where data discovery becomes more than a security exercise. It becomes a compliance engineering problem.
Kyndryl is one of the larger IT services companies now offering data-security capabilities built around Microsoft Purview for hybrid and multi-cloud environments.
The interesting buyer question isn't whether automated data discovery exists.
It's how far it actually reaches.
The three data-discovery problems

This is why "we have a data discovery tool" isn't the end of the discussion.
For buyers evaluating data-discovery platforms, the harder question is often not whether a tool can find and classify data, but whether it can provide enough coverage and evidence to support the actual compliance decision. Analyst Layer approaches these technology decisions from the buyer's perspective, looking beyond vendor claims to understand what a solution actually covers, where the gaps and trade-offs sit, and what buyers need to verify before relying on it.

The architecture of the discovery problem matters.
A scanner connected to your current cloud environment may give you excellent coverage of the systems you already know about while completely missing the systems nobody remembers.
1. Does the tool find personal data everywhere, or only in modern systems?
This is the first test I would run.
A tool that searches current cloud storage and well-known applications may work perfectly — while still failing to answer the actual compliance question.

The risk may be sitting in an old file share that hasn't been touched since the last migration.

Our take: Kyndryl's data-security offering, built on Microsoft Purview, is designed to work across hybrid and multi-cloud environments. That gives it a credible foundation for broad data discovery.

What is less clear from public material is how effectively that coverage extends into genuinely old environments: retired file shares, legacy systems that never moved to the cloud, or storage repositories that have effectively become invisible to current operations teams.
Ask for a real example of the tool finding personal data in an old, forgotten system — not a cloud environment it was already designed to search.

For an engineering team, this should be a live test rather than a slide.
Give the vendor a representative legacy repository and see what it actually finds.
2. Does it classify personal data using this law's categories, or generic security labels?
Finding data is only half the problem.
The next question is what the system thinks that data actually is.
A data-protection law may distinguish between personal data and specific categories of sensitive personal data. A security platform may use its own classification system based on broader concepts such as confidential, sensitive, or regulated information.
Those aren't automatically equivalent.
Our reading: we could not find Kyndryl's data-security work publicly tied to another country's personal-data law as a specific implementation example.

That doesn't mean the platform cannot support the required classification.
It means the mapping needs to be demonstrated rather than assumed.
Ask the vendor to show, in writing, how its data classifications map onto the law's specific definitions — not just onto generic labels such as "sensitive" or "confidential."

For developers and security engineers, the useful artifact here is a classification matrix.
You want to know exactly which detection rule maps to which legal category and what happens when the system isn't confident.
3. What happens when the data sits with an outside vendor?
This is where a purely technical view of data discovery starts to break down.
A company can have excellent visibility into its own databases and still have a blind spot if personal data has been copied into a contractor's environment.

The data may no longer be physically inside your infrastructure.
The responsibility may not have disappeared with it.
Our reading: Kyndryl's own data-processing terms describe its role as a processor of client data. That's a normal company-to-company processing relationship.

But that's different from answering whether the discovery tooling also provides visibility into your organization's third-party vendors and the personal data those vendors hold on your behalf.
Ask whether the coverage includes personal data held by your own vendors, or only data sitting inside your company's systems.
From an implementation perspective, this is not something a scanner alone can necessarily solve.
You may need a combination of data inventories, vendor registers, contracts, questionnaires, API integrations, and evidence from the third party itself.

4. What happens to backup copies when someone asks for deletion?
This is one of those problems that looks simple until you draw the actual data architecture.
A user record exists in the production database.
It gets copied into a data warehouse.
A backup job captures it.
A disaster-recovery system replicates it.
An archive retains another version.
Now someone requests deletion.
Deleting the production record is one operation.
Knowing where all the other copies are — and what your policy requires you to do with them — is another.

Our reading: public material describes capabilities around finding, classifying, and protecting personal data. What is less clear is a concrete walkthrough showing how backup and archive copies are handled following a deletion request.

Ask for a specific walkthrough of what happens to backup and archive copies after a deletion request — not just the copy in the live production system.

For engineering teams, this should be tested against the actual backup architecture.
If the answer depends on retention policies, immutable backups, restore procedures, or scheduled expiration, those dependencies should be documented before the compliance deadline arrives.

5. How fast can the system turn a request into an answer?
A compliance deadline changes the engineering requirement.
It's not enough to eventually find the data.
You need to find it within the time allowed to respond.
That means discovery latency matters.
So do query coverage, false positives, false negatives, indexing strategy, connector availability, and the amount of manual investigation required after the automated scan finishes.
Our reading: general capability claims are easy to find in public material.
A specific, timed example — from receiving an actual request to producing the final response — was not.

Ask for one real example: how long did it take, start to finish, to answer a comparable data request in a previous engagement?

And don't accept only the scan time.
Ask for the end-to-end time.
That includes identifying the subject, searching connected systems, validating results, checking third parties, handling exceptions, and producing the evidence needed for the final response.

Where a tool like this fits
A solution built around Microsoft Purview can be a strong fit for an organization that already runs heavily on Microsoft's ecosystem and has most of its data in modern, documented environments.
It becomes particularly useful when the goal is to create one connected view of data across hybrid and multi-cloud environments and improve automated discovery and classification.

Where it does not fit
The fit is less obvious for organizations with large amounts of:
old on-premises infrastructure
legacy or retired systems
non-Microsoft repositories
poorly documented data stores
personal data held primarily by third-party vendors
It is also not enough for an organization that needs to prove, with a real measured number, how quickly it can respond once a legal deadline starts running.
That requires testing the entire workflow, not just the discovery engine.

FAQs

Does this mean Kyndryl's tool doesn't work for this law?
No.
It means the public material does not yet show the capability mapped specifically to this law's rules. That's a diligence gap worth testing, not a verdict on the underlying technology.

Is this problem unique to Kyndryl?
No.
Any large IT services company selling data-discovery capabilities faces the same fundamental challenges: legacy systems, third-party data, and backup copies are where straightforward discovery approaches tend to become complicated.

What's the one thing most buyers forget to ask?
Whether "finding personal data" includes the data sitting with an outside vendor.
Most teams naturally think about their own databases, file systems, and cloud accounts first.
The harder question is what happens to the personal data that left those systems years ago — and whether anyone can still tell you where it went.
For a data-protection deadline, "we have a discovery tool" is not the finish line.
The real test is whether you can identify the data, classify it correctly, account for its copies and third parties, and produce an answer quickly enough to meet the law.

That distinction is particularly important when the deadline is measured in days rather than months, because a discovery platform can appear comprehensive while still leaving important parts of the data environment untested. This analysis examines the practical questions buyers should ask about finding personal data in legacy systems, mapping classifications to legal requirements, accounting for third-party and backup data, and measuring how quickly the full response process can actually run.

Can Agentic AI Actually Work on Top of a System Nobody Fully Understands Anymore?

Deb_Ghosh_Analsyt Layer — Fri, 11 Sep 2026 04:53:49 +0000

Most large companies want AI.
Most large companies also run old, tangled systems that nobody currently on staff fully understands.

The person who originally wrote the logic may have left years ago. The documentation may be incomplete. Business rules may exist only in code, configuration files, database procedures, or the memory of someone who has been maintaining the system for a decade.
And now someone wants an AI agent to build on top of it.

That creates a problem that is easy to underestimate.
Before an agent can safely modify a legacy system, it first needs to understand what that system actually does.

Recent research puts numbers around the size of the problem. Developers spend roughly 58% of their time reading old code, compared with around 5% writing new code. One widely cited study has found that roughly 60% of AI leaders identify legacy systems as a primary barrier to deploying agentic AI.

The legacy-modernization market is growing alongside that pressure, from roughly $29 billion in 2026 to more than $66 billion by 2031.
Thoughtworks has built a specific product around this intersection.
In January 2026, the company launched AI/works, an agentic development platform designed to interpret legacy applications, turn that understanding into structured specifications, enrich those specifications with regulatory and security context, and use agentic workflows to generate code, tests, and deployment pipelines.
That sounds compelling.

But there is one question underneath all of it:
How do you know the AI actually understood the old system correctly?

How big is the pressure, in plain numbers?

The numbers point to an uncomfortable reality.
For many enterprises, the bottleneck isn't the ability to generate new code.
It is understanding the code that already exists.
That makes legacy-system comprehension a potentially valuable first step in an agentic development workflow.
But comprehension is also where the highest-risk assumption enters the process.
If the AI gets the old system wrong, everything built afterward can be wrong in ways that are difficult to detect.

The three shapes of the problem

Agentic AI potentially compresses all three stages.
But they shouldn't be treated as one problem.
Understanding is not specification.
Specification is not implementation.
And generated implementation is not production readiness.

Sector specialty worth naming: teams modernizing a finance or operations backbone
This problem appears inside almost every large organization with an old core system underneath a modern front end.
Banking.
Insurance.
Manufacturing.
Retail.
Government.
The industry changes.
The problem doesn't.
The company worth naming here is Thoughtworks.
In January 2026, it launched AI/works, a named platform specifically positioned around agentic development and legacy modernization.
The workflow is notable because it doesn't begin with "generate some code."
It begins with understanding the existing system.
That is exactly where the following questions matter.

1. Does it actually understand the old system — or just summarize it plausibly?
There is a major difference between an AI system that can produce a convincing description of legacy code and one that can accurately reconstruct the system's actual behavior.
The second is much harder.

A legacy application can contain undocumented dependencies, unusual business rules, dead-looking code that turns out to matter, database procedures, configuration-driven behavior, and years of accumulated exceptions.

A plausible summary can miss any of them.
Our reading: Thoughtworks describes AI/works as using AI-enabled reverse engineering to interpret legacy applications and convert that understanding into structured specifications.
That's a meaningful claim.

Reverse engineering suggests the platform is working from the actual application rather than simply asking an AI model to explain a few code files.
The missing piece is verification.

Ask what the verification step looks like: who checks the AI's understanding of the legacy system against actual system behavior before that understanding becomes the basis for new code?
For a high-stakes system, "the AI understood it" cannot be the final control.

2. Are the "months instead of years" claims measurable?
"Years to months" is probably the most memorable promise in this category.
It is also one of the claims buyers should interrogate most closely.
Modernization projects can take years because the difficult work isn't always writing replacement code. It includes discovering undocumented behavior, validating requirements, testing edge cases, migrating data, integrating surrounding systems, and obtaining approvals.

Our reading: Thoughtworks has publicly described AI/works as enabling modernization work to move from years to months, alongside claims around lower costs and improved code quality.
Those are significant claims.

But as of 6 September 2026, the public material available does not provide enough named, project-level evidence to independently establish how often the full "years to months" outcome has been achieved.
Ask for one named or anonymized customer example with an actual before-and-after timeline — in months, not a general "years to months" comparison.

A 90-day pilot is interesting.
A production modernization of a genuinely tangled legacy system completed in 90 days is a much stronger proof point.

3. What happens when the business rules change after the new system goes live?
Modernization has a recurring problem.
The new system eventually becomes the old system.
If requirements change through manual patches, undocumented workarounds, and one-off fixes, the organization can recreate exactly the maintenance problem it was trying to escape.
Our reading: Thoughtworks describes AI/works as supporting an ongoing development model in which affected components can be regenerated when requirements change.

That is a particularly interesting part of the proposition.
The goal isn't simply to modernize once.
It is to make future change easier.
Ask for a real example of a requirement changing after go-live, and exactly what was regenerated automatically versus what still required human intervention.

This is where the difference between an AI coding tool and an actual modernization workflow becomes clearer.

4. Does it work the same way on a regulated system?
A legacy retail inventory application and a core banking system may both contain old code.

They do not carry the same risk.
In regulated environments, a small misunderstanding of a business rule can have consequences far beyond a failed application test.
There may also be requirements around security, auditability, traceability, data handling, and regulatory controls.
Our reading: Thoughtworks states that the specifications generated through its approach can be enriched with regulatory, security, and industry context.

That is highly relevant for regulated enterprises.
But the important question is how that context is validated in production environments where correctness matters more than speed.
Ask for a specific example from banking, insurance, healthcare, or another regulated environment where the approach was used on a genuinely high-stakes legacy system.

"Regulatory context is included" is a capability statement.
A regulated production example is evidence.

5. How does the 90-day delivery promise hold up on a genuinely tangled system?
The 3-3-3 model, positioning idea-to-production delivery within 90 days, is unusually specific.
That is useful.

Specific promises can actually be tested.
But there is an obvious selection effect to watch for.
A clean, well-scoped application with a small number of dependencies is very different from the oldest, most complicated system in an enterprise estate.

Our reading: The 90-day model is an attractive and testable proposition, but buyers should distinguish between a controlled modernization pilot and the hardest production system they own.
Ask which past projects actually used the full 90-day model end to end, and how large, interconnected, and difficult those systems were.
The strongest proof isn't the easiest system that can be modernized in 90 days.

It's the difficult one.

Where it fits
A large organization with genuinely painful legacy systems, significant technical debt, and a need to modernize faster than a traditional multi-year rewrite would allow.

It is particularly interesting for enterprises operating a hybrid estate where old core systems still support important business processes while newer applications and AI capabilities are being introduced around them.
Where it does not fit

A company expecting to remove human verification entirely from the modernization of a regulated or high-stakes system.
It is also a poor fit for a buyer assuming that a 90-day delivery model automatically applies to the most complex system in the estate without first validating the approach through a properly scoped pilot.

FAQs

1. Is this just outsourced development with AI added to the process?
Based on the public positioning, no.
The more distinctive part of the approach is the sequence: reverse-engineering the existing application, turning that understanding into structured specifications, and then using agentic workflows to generate implementation artifacts from those specifications.
That is materially different from simply giving developers an AI coding assistant.
The important caveat is that the approach is still relatively new, so independent large-scale evidence remains limited.

2. Is Thoughtworks the only company working on this?
No.
Major technology and professional-services firms are investing heavily in agentic development.
The more specific distinction here is the legacy-first approach: understanding an existing system before using agents to build or modify it.
That is a narrower problem than general AI-assisted software development.

3. What's the one thing most buyers forget to check?
Whether "understood by AI" has actually been verified against the real system.
The dangerous failure mode isn't an obviously broken AI output.
It's a plausible interpretation that quietly misses one undocumented business rule.
If that interpretation becomes the specification, and the specification becomes the code, the original misunderstanding can propagate through the entire modernization process.

Our reading
Agentic AI may eventually change legacy modernization in a fundamental way.

But the breakthrough isn't simply AI writing the replacement code.
The harder problem is getting the machine to understand what the old system actually does before anyone decides what should replace it.
That makes the most important control point the beginning of the workflow, not the end.

For buyers evaluating Thoughtworks or any similar approach, the questions worth pressing are straightforward:
How is the legacy system understood?
How is that understanding verified?
How does it become a specification?
What happens when requirements change?
And what evidence exists from genuinely complex production systems?

If those questions have good answers, agentic modernization becomes much more interesting.

If they don't, the organization may simply be moving faster toward a system it still doesn't fully understand.

And that is a very modern way to recreate a very old problem.

Questions Buyers Are Asking: Who Actually Finds the Hidden Inefficiency Inside a GCC Before an Audit Does?

Deb_Ghosh_Analsyt Layer — Thu, 10 Sep 2026 08:39:58 +0000

A global capability centre often starts as a cost-saving back office.
Then it grows.
Within a few years, it may be running finance operations, customer workflows, technology services, procurement, analytics, or entire business processes for the parent company.
And somewhere in that growth, the processes get tangled.
Extra approval steps nobody remembers adding. Manual workarounds that became permanent. Exceptions that quietly became the standard process. Controls that exist in documentation but not in the system.
The difficult part isn't always finding a problem after something goes wrong.
It's finding it before an audit does.
That is where process mining is becoming an increasingly important technology category.
The global process mining market is projected to grow from roughly $4.6 billion in 2026 to more than $15 billion by 2032, with annual growth estimated at around 22%.
For GCCs, the appeal is straightforward: instead of relying entirely on interviews, process documentation, or periodic audits, process mining can use actual system event data to show how work is really moving through an organisation.
KPMG has built a genuine, named position at the governance end of this problem for GCCs specifically.
The more interesting question is how far that position extends into the technical work underneath it.

How big is this getting, in plain numbers?

The numbers explain why process mining has moved beyond being an interesting analytics capability.
It is becoming a dedicated enterprise software category.
But the technology itself is only one part of the GCC problem.
The bigger question is what happens after the software identifies the inefficiency.

The three shapes of the problem, side by side

This distinction matters because a process-mining project can sit in more than one of these categories.
It can be a technical analytics exercise.
It can be a transformation project.
Or it can become part of the governance and control environment.
Those are not interchangeable use cases.

Sector specialty worth naming: risk, governance, and audit oversight inside GCCs
This function exists inside mature GCCs regardless of industry.
Banking, energy, manufacturing, healthcare, consumer goods — once a centre becomes sufficiently large and operationally important, the same governance problem appears.

The company worth naming here is KPMG.
KPMG has a dedicated GCC practice publicly positioned through its OneGCC framework, alongside a confirmed strategic partnership with Celonis, one of the major process-mining platforms.

That combination is interesting because it brings together two different capabilities:
governance and advisory expertise on one side, and process-mining technology on the other.

The questions for buyers are therefore less about whether the capability exists and more about who actually does what.
For GCC leaders evaluating a process-mining or transformation engagement, the challenge is often less about identifying vendors and more about understanding where each provider's actual responsibilities, capabilities, and limitations begin and end. Analyst Layer helps technology and business decision-makers approach those questions from the buyer's side, combining market intelligence and primary research to distinguish between vendor positioning, delivery capability, and evidence that can be tested during due diligence.

1. Is the process-mining work KPMG's own technical build, or a partner's?
Process mining isn't just a consulting slide.
To work properly, it needs access to actual enterprise-system data.
That can mean connecting ERP, CRM, workflow, ticketing, procurement, finance, or other operational systems; extracting event logs; constructing process models; and tuning those models to identify deviations and bottlenecks.

Our reading: KPMG's process-mining capability is publicly associated with its confirmed partnership with Celonis rather than an entirely KPMG-built process-mining platform.

That is a perfectly reasonable delivery model.
In fact, using a specialist platform can provide capabilities that would be expensive to reproduce internally.

But it creates an important architectural question: where does the technical platform end and the consulting service begin?
Ask exactly which parts of the engagement are delivered by KPMG's own technical team and which parts depend on the Celonis platform underneath.
For a GCC technology leader, that distinction matters for architecture, ownership, licensing, data access, and long-term operating costs.

2. Is KPMG positioned for deep technical delivery, or primarily for governance and oversight?
There is an important difference between identifying a process-control problem and engineering the technology required to permanently fix it.
Large professional-services firms often have strong capabilities across both areas, but their centre of gravity can differ.

Our reading: KPMG's GCC positioning is particularly strong around governance, risk, compliance, internal controls, cybersecurity oversight, and audit readiness. That is different from a technology-delivery provider whose primary mandate might be building applications, integrations, automation, or infrastructure.

Neither model is inherently better.

The question is which one the GCC actually needs.
Ask for a specific example of KPMG's team performing hands-on technical implementation — not just process assessment, governance design, or oversight — if technical delivery is part of your requirement.
This is especially important when the GCC already has an incumbent technology-services provider.

3. Does finding the inefficiency also mean fixing it?
This is where process mining gets interesting.
A platform can show that a procurement process has ten approval steps when only four are actually required.

It can identify invoices repeatedly falling into exception queues.
It can show where cases wait for days before the next activity happens.
But identifying the problem isn't the same as changing the process.

Our reading: KPMG's public positioning covers the broader GCC lifecycle — from setup and scaling through transformation — suggesting that the engagement can extend beyond simply identifying inefficiencies.
But buyers should distinguish between diagnosis and measurable remediation.

Ask for one real example: a process that was mapped, redesigned, implemented, and measured before and after the intervention.
If the answer ends at "we identified the bottleneck," you have bought visibility.

If the answer includes a measurable reduction in cycle time, exceptions, manual steps, or cost, you have bought transformation.
Those are different outcomes.

4. How does this differ from what the GCC's existing technology partner already does?
This is one of the easiest questions to overlook.
Many GCCs already have technology-services partners responsible for applications, integrations, automation, cloud, ERP, or day-to-day technology operations.

Then a process-mining engagement arrives and starts analysing the same workflows.
That can create overlap.
Or it can create a useful division of responsibility.

Our reading: The distinction should be established before implementation. A governance-led process-mining engagement can complement an existing technology partner, but only if ownership of remediation is clearly defined.
Ask how the process-mining team will work with your existing technology delivery partner — and who owns the actual remediation once an inefficiency is identified.
Finding the problem is only valuable if somebody has the authority and capability to fix it.

5. What does "success" actually look like in a number?
This is the question that turns a technology demonstration into a business case.
Process mining is often presented through impressive visualisations: process maps, bottleneck charts, deviation analysis, and automated insights.
But a GCC leadership team ultimately needs something more concrete.
Did cycle time fall?
Did manual touches decrease?
Did exceptions decline?
Did compliance improve?
Did operating cost fall?

Our reading: A frequently cited industry figure is a roughly 30–40% reduction in process deviation from AI-enabled process mining. That is useful as an industry benchmark, but it should not automatically be interpreted as a KPMG-specific result or a GCC-specific guarantee.
Ask for KPMG's own measurable result from a comparable GCC engagement — ideally with a before-and-after metric attached.
A dashboard is not the outcome.
The operational improvement is.

Where it fits
A maturing GCC that needs stronger governance, risk management, audit readiness, and process visibility, particularly where a separate technology-delivery capability already exists or can handle the underlying remediation work.

It is especially relevant when the centre has enough operational complexity that interviews and manually maintained process documentation no longer provide a reliable picture of how work actually happens.

Where it does not fit
A GCC looking for a single partner to own everything — process discovery, deep technical implementation, application engineering, automation, and governance — without involving a separate delivery capability.
That combination is not clearly what this offering is built around.

FAQs
1. Is KPMG's process-mining capability real, or just a partnership label?
It is a real capability backed by a confirmed strategic relationship with Celonis, an established process-mining platform.
The more important question is how that platform is incorporated into the specific engagement and what KPMG's team is responsible for delivering around it.
2. Is the governance-versus-delivery distinction unique to KPMG?
No.
The split appears across the broader GCC services market.
Audit- and advisory-led firms often approach GCCs through governance, risk, compliance, and transformation, while technology-services firms tend to lead with engineering and delivery.
The distinction is useful when comparing providers.

3. What's the one thing most GCC leaders forget to ask?
Who fixes the problem after the process-mining platform finds it?
If a system identifies a broken workflow, excessive approvals, or a recurring exception, somebody still has to redesign the process, change the technology, update the controls, and measure whether the fix worked.
That ownership should be clear before the engagement begins.

Our reading
Process mining is becoming a meaningful technology layer for mature GCCs because it changes the question from:
"What do we think our process looks like?"
to:
"What does the system data show our process actually looks like?"
That is a valuable shift.

But the technology alone doesn't determine the outcome.
For buyers evaluating KPMG or another provider, the more useful diligence questions are about technical ownership, remediation responsibility, integration with existing technology partners, and measurable business outcomes.

The best process-mining engagement isn't the one that produces the most impressive process map.
It's the one that finds something the organisation didn't know was broken — and then proves that it was actually fixed.

For GCC leaders considering process mining, the practical decision therefore comes down to more than the strength of the underlying platform. It requires a clear view of technical ownership, governance responsibilities, remediation capability, and the evidence a provider can produce from comparable engagements. This coverage examines those questions from a buyer's perspective, focusing on what organisations should verify before treating process mining as a genuine operational-improvement capability rather than simply another analytics layer.

Who Actually Closes the Books Fast Across a Messy Group of Companies?

Deb_Ghosh_Analsyt Layer — Wed, 09 Sep 2026 09:38:27 +0000

For most finance teams, closing the books for one entity is not the hard part anymore.
The real challenge comes when a company has grown through acquisition, operates several general ledgers, uses different currencies and accounting structures, and still needs one clean, audit-ready number quickly.
That is exactly where financial consolidation platforms are supposed to help.
The financial consolidation software market is projected to grow from roughly $3.5 billion in 2026 to nearly $8 billion within a decade. Oracle is a genuine market leader in the category, with approximately 20.3% EPM market share and a Leader position in Gartner's Magic Quadrant.
But market position is not the same thing as proving that a platform can handle a company's messiest consolidation problems.

The real problem is not the clean close
There are three increasingly difficult versions of the close.
A single-entity close involves a standard month-end process using one clean chart of accounts.

A multi-entity consolidation requires several entities, currencies and ownership structures to be combined into one set of financial statements.

A post-acquisition, multi-system consolidation is more difficult because the entities may not share either the same chart of accounts or the same source system.

That last scenario is where the real test begins.
The slowest legacy system feeding the consolidation can determine how quickly the entire process gets completed.

Why Oracle is worth examining
Oracle's Financial Consolidation and Close Cloud Service has several capabilities that directly address this problem.
It supports automated trial balance loading from heterogeneous source systems, both PVA and VAL currency translation methods, automated intercompany eliminations, multi-GAAP reporting for local GAAP and IFRS side by side, and embedded AI that sequences close tasks and monitors entity status.

Those are substantial capabilities.
But buyers should still test how they perform against real implementation challenges rather than relying on a clean product demonstration.

That is also why enterprise software evaluation increasingly needs to go beyond product claims and feature comparisons. Understanding what buyers are actually prioritizing, which alternatives they are weighing, and where implementation concerns are surfacing can provide a much clearer picture of how a platform will perform in a real buying process.

1. Does the automation work before the data is clean?
This is one of the most important questions for companies that have acquired other businesses.
Oracle describes automated trial balance loading from heterogeneous source systems as a genuine capability. However, independent implementation guidance identifies chart-of-accounts mapping between legacy systems and Oracle's target structure as a common challenge, particularly after mergers and acquisitions.

Our reading: Oracle has a real strength in automated loading, but buyers should distinguish between automating consolidation and solving the structural differences that exist between source systems.

The useful test is simple:
Ask for a specific, timed example of onboarding a newly acquired entity with a different chart of accounts.
A demonstration involving entities that are already mapped does not answer the harder question.

2. Is the 25% faster close actually Oracle-specific?
Reported improvements from modern cloud EPM platforms include faster close cycles and better forecast accuracy.

The specific figures identified here — approximately 25% faster close and 30–35% better forecast accuracy — come from case material involving a move from legacy systems to Oracle Fusion.

That makes the figures useful and attributable.
But it is still reasonable to ask whether a competing modern platform could produce a similar result.

Our reading: the improvement is a real documented data point, but it should not automatically be interpreted as proof that Oracle outperforms every modern alternative.

Ask for a comparison, where one exists, between Oracle's results and those of a competing modern platform for a similarly complex client.

3. Is the platform really easy for finance users?
Enterprise software creates an obvious tension between configurability and simplicity.
A platform capable of handling complex entity structures may require considerable specialist knowledge to configure.

Independent review material from BARC describes Oracle Cloud EPM as "a good tool" while also noting that it is still lacking in user-friendliness and performance.

Oracle's own material says non-technical finance users can configure entity hierarchies and rules through wizards.

Our reading: the evidence is balanced enough that usability should be tested directly.
Don't just ask whether finance users can configure the system.
Ask them to prove it.
Ask to see a non-technical finance user configure a new consolidation rule live, without a consultant driving the keyboard.

4. What happens at real enterprise scale?
A demonstration involving a small number of straightforward entities tells you relatively little.
Independent evaluation guidance recommends testing around 75 entities with equity method accounting, proportional consolidation, minority interest and multi-GAAP reporting together.

That is a much more meaningful test of consolidation complexity.
Our reading: scale and accounting complexity are where meaningful differences between platforms are more likely to emerge.
The right demonstration should resemble the organization's actual structure rather than an artificially simplified reference scenario.

5. What happens when an intercompany elimination fails?
A successful elimination is easy to demonstrate.
A failed elimination is much more revealing.
The important question is how quickly a controller can identify the problem, understand what happened and correct it while maintaining a clear audit trail.

Our reading: this is one of the most concrete capabilities a buyer can test instead of simply accepting a vendor claim.
Ask for a live demonstration of an intercompany elimination that does not balance — and exactly how the system helps the controller find and fix it.

Where Oracle fits
Oracle makes the strongest case for a large enterprise with a genuinely complex multi-entity structure, particularly where other Oracle applications are already in use.

It also makes more sense when the organization has the internal resources or partner support required for a substantial initial implementation.

Where it does not fit
A mid-market company with a simpler entity structure may not need the depth of an enterprise-tier EPM suite.
Several independent comparisons position lighter tools as a better fit below a certain level of c

omplexity.
Oracle is also not the easiest choice for a company expecting a fast, lightly configured rollout without dedicated implementation resources.
The question buyers should remember
The most useful question is not simply:
"How fast can your platform close the books?"
It is:
"How fast can you close the books when the newest entity has a different chart of accounts, comes from a legacy system, and its intercompany elimination does not balance?"
That is where the difference between a polished consolidation demonstration and a genuinely useful enterprise platform becomes much easier to see.

This is a piece of opinion — our reading of what buyers should ask, based on public material available as of the date noted above. It is not a statement of fact about any company. No company mentioned pays for the mention. Any company named here can write to hello@analystlayer.com; we respond within three working days and update the piece where the input is factual, with the update dated on this page.

Being Recommended Isn't Being Considered: The Gap Between an AI Mention and a Sales Meeting

Deb_Ghosh_Analsyt Layer — Wed, 26 Aug 2026 06:03:59 +0000

Getting named by an AI assistant is not the same as being in a real deal. When a tool like ChatGPT or Perplexity lists your company as a good option for a problem, that is a recommendation — a moment of visibility. A sales meeting, by contrast, means a specific person at a named account has decided your product is worth their time. The gap between the two is large, and closing it is a different job entirely: it takes knowing which accounts are actually forming demand right now, and reaching the right people there with a reason to talk. This article explains why the gap exists, why chasing AI mentions can mislead you, and what actually turns visibility into a conversation.

What is the difference between an AI recommendation and a sales meeting?
An AI recommendation is generic. A sales meeting is specific. That is the whole difference in one line.

When someone asks an AI assistant "what are the best tools for data governance," the model returns a list based on what it has read across the public internet. Your name appearing there tells you that your marketing content, reviews, and public presence are strong enough for a model to associate you with a category. That is genuinely useful — it means you exist in the model's picture of your market.

But a recommendation has no target. It does not tell you who asked, whether they had budget, whether they were a real buyer or a student writing an essay, or whether the company behind the question is one you could ever win. A sales meeting has all of that context baked in. It is anchored to a named account, a named person, and a real, forming need.
Here is the gap laid out plainly:

Why does being recommended feel like progress when it often isn't?
Because visibility is easy to measure and easy to celebrate. You can screenshot an AI mentioning your name and share it with your leadership. It looks like winning.

The trouble is that visibility and demand are not the same thing. A recommendation is one-to-many and anonymous. It scatters your name across every person who happens to type a question — most of whom will never be your customer. For enterprise technology vendors, this is a poor fit for how the market actually works.

This is what we call the finite-account world. For most enterprise technology vendors, the list of accounts genuinely worth winning is small and knowable — often a few hundred companies, not millions. Being recommended broadly to an anonymous crowd does very little for a business whose real prize is thirty specific accounts. You do not need to be mentioned more often. You need to be considered by the right thirty.
So an AI mention can feel like momentum while leaving your actual pipeline untouched. It is motion without direction.

When does an AI mention actually matter?
An AI mention matters when it happens inside an account you are already trying to win, in the mind of a person who is actually evaluating options. That version is valuable. The problem is you usually cannot tell the difference from the outside — the mention itself carries no identity.
AI visibility is best understood as table stakes: a reason not to be excluded, rather than a reason to be chosen. If a serious buyer asks an assistant to shortlist tools and you are absent, that hurts. Being present keeps you eligible. But eligibility is the floor, not the finish line.
Think of it the way a strong reputation works for a hiring candidate. Being well-regarded in your field gets your name into conversations. It does not get you the specific job. Someone still has to decide to interview you, for this role, at this moment. The interview is the meeting. The reputation is the recommendation.

How do you turn a recommendation into a real conversation?
You stop optimizing for being mentioned and start working named accounts directly. The bridge between visibility and a meeting is account-specific intelligence — knowing which companies are forming demand now, and why.

Analyst Layer fits into this gap between visibility and action by helping teams look beyond broad AI recommendations and focus on the signals emerging inside specific accounts. Instead of asking only where a company is being mentioned, an analyst-led view considers what is changing within a target account, which priorities are gaining attention, and whether those signals suggest a conversation is becoming timely. That turns market visibility into a more useful starting point for account-level action.

Here is the difference in approach:
Recommendation-chasing asks: How do I get named more often across the whole market?

Demand-led work asks: Which of my finite set of target accounts is moving toward this problem right now, and what is the real reason to reach out?
The second question is the one that produces meetings. It replaces spraying your name widely with finding real, forming demand and shaping it before a deal is obvious. This is the difference between sales enablement — helping sellers sell better once a deal already exists — and demand enablement, which is the earlier, harder job of finding the deal before it is obvious and shaping it while it is still forming.

Concretely, turning a recommendation into a conversation looks like this:
Define the finite list. Name the accounts actually worth winning. Not thousands — the real, knowable set.

Find forming demand inside them. Look for genuine signals that a specific account is moving toward the problem you solve — a new leader with a known agenda, a public commitment to a program, a shift in how they describe their priorities.

Arrive with a point of view. Reach the right person with a sourced, specific read on their situation — not a generic pitch triggered by a category mention.

Move from intelligence to execution. Use that read to open a real conversation, then support the deal as it forms.
This is demand-led innovation in practice: innovation and outreach follow real demand in a leader's own market, rather than starting from "we exist, please consider us."

Why does account-level intelligence beat broad AI visibility for enterprise vendors?
Because the math of the finite-account world makes broad tactics self-defeating. If your prize is a few hundred accounts, being recommended to a million anonymous questioners is almost all waste. Depth beats breadth.
Consider a vendor selling a specialized security platform. Being mentioned by an AI assistant in thousands of generic "best security tools" answers generates noise — students, competitors, tiny companies that will never buy. Meanwhile, the twelve global banks that are actually its real market may never surface in that visibility at all. The recommendation metric goes up; the pipeline that matters does not move.

Account-level intelligence inverts this. Instead of measuring how widely you are named, it measures whether you are close to the specific accounts that can change your year — and whether you understand their forming needs well enough to earn a conversation. That is why we describe ourselves as a data company: what matters is intelligence about named accounts, not visibility in the abstract.

This is the role of B2B intelligence in an enterprise sales motion: connecting account-level changes with the business and technology priorities behind them. Rather than treating every interaction as equal, B2B intelligence helps teams understand which companies are moving toward a particular problem, what may be driving that movement, and where a timely conversation could make a difference. In a finite-account market, that context is often more valuable than simply knowing how visible a brand is across AI answers.

And it must be trustworthy. Every claim about an account should trace to a real source. That is responsible intelligence: when we point a vendor at an account, we stand behind why. A recommendation from a model that cannot show its reasoning is fragile. A read on an account that traces to real, checkable signals is something you can act on with confidence.

When is chasing AI visibility actually the right move?
There are cases where broad visibility genuinely helps, and it is honest to name them.

If you sell to a large, fragmented market — say, a self-serve tool bought by millions of individuals or small teams — then broad AI recommendation can drive real volume, because your buyer really could be anyone typing the question.
If you are a brand-new category entrant and almost no one knows you exist, showing up in AI answers builds the baseline awareness you need before deeper work can pay off.
If your category is defined largely by public reputation, being consistently recommended reinforces credibility that supports later, deeper conversations.

But for the classic enterprise technology vendor — a small, knowable set of large accounts, long deals, real decision-makers — visibility is the floor, and account-level demand work is where meetings actually come from.

Frequently asked questions

- Does appearing in ChatGPT or Perplexity answers generate enterprise sales leads?
Rarely on its own. An AI mention makes you visible in a category, but it is anonymous and untargeted, so it does not tell you which real account is interested or why. For enterprise vendors with a small set of target accounts, visibility keeps you eligible but does not produce named, workable meetings.

- What is the difference between demand enablement and sales enablement?
Sales enablement helps sellers close deals that already exist. Demand enablement is the earlier job: finding real demand as it forms inside specific accounts and shaping it before a deal is obvious. One works an existing pipeline; the other creates the pipeline in the first place.

- How do I turn AI visibility into actual sales meetings?
Stop treating being mentioned as the goal and start working named accounts directly. Identify the finite set of accounts worth winning, find genuine signals of forming demand inside them, and reach the right person with a specific, sourced point of view rather than a generic pitch.

- What is the finite-account world?
It is the reality that, for most enterprise technology vendors, the list of accounts actually worth winning is small and knowable — often a few hundred companies. Because that set is finite, broad volume tactics are arithmetically wasteful, and deep, named-account intelligence is the motion that fits.

- Is being recommended by AI worthless for B2B companies?
No — it is table stakes. Being present in AI answers keeps you eligible and avoids being excluded when someone shortlists options. It just is not the same as being considered, and it should not be mistaken for pipeline progress on its own.

- How do you know an account is actually forming demand?
By tracing it to real, checkable signals — a new leader with a public agenda, a stated program, a shift in stated priorities — not by guessing from category-level noise. This is responsible intelligence: every claim traces to a real source, so when you reach out, you can stand behind why.

The short version
Being recommended by an AI is not the same as being considered by a buyer. A recommendation is broad, anonymous, and untargeted; a sales meeting is specific to a named person at a named account with a real, forming need. For enterprise technology vendors operating in the finite-account world, broad AI visibility is table stakes — useful for staying eligible, but no substitute for pipeline. The work that actually produces meetings is demand enablement: finding real, forming demand inside your target accounts and arriving with a sourced point of view, moving from intelligence to execution rather than counting mentions.

Public Cloud vs. Hybrid Cloud for Regulated Enterprises

Deb_Ghosh_Analsyt Layer — Mon, 17 Aug 2026 11:23:47 +0000

For regulated enterprises, hybrid cloud is the only viable architecture for core operations, while public cloud serves strictly as a tool for secondary systems and sudden traffic spikes. If a company handles financial transactions, patient health records, or legally restricted data, it must use a hybrid model to keep sensitive information in a private, fully controlled environment. A pure public cloud is the right choice only when an enterprise is running non-critical workloads, such as testing environments or public-facing marketing websites, where data exposure carries no legal or financial penalty.

At Analyst Layer, our work is built entirely on demand-led innovation. We study the real, forming demand of senior technology leaders instead of starting with whatever new features a technology vendor wants to push. In the finite-account world of enterprise technology, the number of massive financial, healthcare, and infrastructure organizations is small, and their technical constraints are absolute. Understanding these unyielding constraints is the foundation of demand enablement. Because we practice responsible intelligence, every architectural recommendation or market observation we make is traced to real-world trade-offs, not vendor marketing material. We arrive with a point of view before you hire us, and our perspective on cloud deployment for regulated industries is straightforward: you cannot outsource compliance. Taking a cloud strategy from intelligence to execution means placing every workload exactly where it legally, functionally, and securely belongs. Volume tactics and one-size-fits-all cloud migrations simply fail in this environment.

What makes hybrid cloud the mandatory standard for sensitive data?

A hybrid cloud combines the absolute control of a private, dedicated infrastructure with the flexible scale of a shared public environment. In industries like banking and healthcare, data must be tightly secured to meet strict regulatory standards governing personal health information or banking privacy. By keeping core transaction databases or patient record systems in a private data center—or a privately hosted environment—an organization maintains total authority over who accesses the underlying hardware and exactly where the data physically resides.

The public cloud portion of the hybrid setup is then securely connected to handle auxiliary tasks or absorb sudden increases in user traffic. For example, a global retail bank will run its central financial ledger on isolated private infrastructure. However, it will seamlessly connect that ledger to Amazon Web Services (AWS) or Microsoft Azure to host its customer-facing mobile banking application interface. The application lives in the public cloud, but the critical data it accesses remains locked in the private cloud. This split ensures the enterprise remains fully compliant with privacy regulations while still delivering a modern, fast digital experience to its end users.

When should a regulated enterprise choose a pure public cloud?

A pure public cloud is the correct choice only when speed, cost-efficiency, and global reach matter more than hardware-level control and strict data privacy. In a public cloud, third-party providers own the servers, and computing resources are shared among thousands of different organizations. You should choose this model exclusively for workloads that carry zero regulatory risk and contain no sensitive personal information.

For instance, a vast hospital network must secure its electronic health records privately, but it should absolutely use a public cloud like Google Cloud Platform to host its public informational website, its employee training video portals, and its software development and testing environments. In these specific scenarios, the lower upfront costs, zero-maintenance hardware, and rapid scaling of public cloud platforms provide massive advantages. Because there is no sensitive customer or patient data involved in these edge systems, the enterprise faces no legal or financial penalty if the shared infrastructure experiences a broader issue or requires migration.

How does the shared infrastructure of public cloud introduce compliance risks?

Public clouds operate much like a massive commercial office building: your specific corporate office is locked, but you share the plumbing, electricity, climate control, and underlying physical foundation with every other tenant. This shared multi-tenant model inherently removes an organization's ability to dictate exactly which physical server rack holds its data at any given second.

For many regulated enterprises, this lack of absolute physical control violates data sovereignty laws. These laws legally mandate that citizen data must remain within specific geographical boundaries and under direct, auditable corporate control. Furthermore, securing a public cloud relies entirely on a shared responsibility model. The cloud provider secures the building's perimeter and the physical servers, but the enterprise must configure its own software locks perfectly. A single misconfigured access policy or exposed access key in a public cloud storage bucket can immediately expose millions of records to the open internet. Regulated industries mitigate this unacceptable risk by keeping their most sensitive data within the walled garden of a private or hybrid environment, where they control the physical hardware, the network perimeter, and the software stack simultaneously.

How do technology leaders split workloads in a hybrid cloud environment?

The mechanical success of a hybrid cloud relies on seamlessly splitting workloads based on data sensitivity and computing demand. The integration between the private and public sides is typically managed through secure application programming interfaces (APIs) and encrypted virtual private networks. This architecture enables a highly effective strategy known as "cloud bursting."

Consider a heavily regulated credit card provider. On a normal day, the company keeps its transaction processing securely locked down in its private cloud. However, if that company runs a massive holiday promotion that drives a sudden, unpredictable surge of traffic to its rewards portal, the private infrastructure might struggle to keep up. Instead of crashing, the hybrid system dynamically "bursts" the excess web traffic into the public cloud, temporarily renting the necessary computing power. The initial customer interaction is processed using the massive scale of the public cloud, but the sensitive financial data required to complete the transaction is immediately routed back and stored in the secure, private environment. Once the traffic spike subsides, the public cloud resources are released, and the enterprise stops paying for them.

Public Cloud vs. Hybrid Cloud for Regulated Environments

Frequently Asked Questions

- What is the main difference between public cloud vs hybrid cloud?
A public cloud is a shared computing environment owned and operated entirely by a third-party provider, accessed over the internet. A hybrid cloud is a mixed computing environment that combines a dedicated, privately owned infrastructure with public cloud resources, allowing data to move securely between the two. The core difference is that hybrid gives you physical control over sensitive data, while public cloud requires you to share underlying hardware.

- Why do banks and healthcare companies use hybrid cloud?
Banks and healthcare companies use hybrid cloud because strict regulations govern how they store financial transactions and patient health records. They are legally required to maintain absolute control over sensitive data, which is only guaranteed in a private environment. They use the public portion of the hybrid cloud purely to run customer-facing applications and manage periods of high web traffic.

- Can a regulated enterprise use a public cloud safely?
A regulated enterprise can use a public cloud safely only if it restricts that environment to non-sensitive, unregulated workloads. Tasks like software development, public marketing websites, and general employee training portals are perfectly safe in a public cloud. Highly sensitive customer data or core operational ledgers should never be placed in a pure public cloud environment due to compliance and security risks.

- What are the cost differences between public and hybrid cloud models?
Public cloud operates on a pay-as-you-go model with zero upfront hardware costs, making it cheaper to launch but potentially expensive as usage scales continuously. Hybrid cloud requires a significant initial capital investment to build and maintain the private infrastructure portion. However, hybrid models optimize long-term costs by allowing companies to run baseline operations predictably on owned hardware while renting public cloud space only during demand spikes.

- How does a hybrid cloud architecture help with data sovereignty?
Data sovereignty laws require that specific types of citizen data physically remain within certain borders or under direct corporate governance. A hybrid cloud architecture solves this by allowing an enterprise to store all regulated data locally on its private servers to satisfy legal requirements. The enterprise can then run its global applications in the public cloud, pulling data securely from the private local servers only when actively needed.

The short version
For regulated enterprises, hybrid cloud is the mandatory architecture for any system handling sensitive, regulated, or core operational data. By combining a highly secure private infrastructure with scalable public resources, organizations can meet strict legal compliance mandates without sacrificing digital performance. A pure public cloud should be leveraged exclusively for non-critical edge applications and testing environments where data exposure presents no regulatory or financial risk.

One data platform or many? The real trade-off

Deb_Ghosh_Analsyt Layer — Wed, 12 Aug 2026 08:40:29 +0000

The right answer for most enterprise technology teams is to start with one platform as the spine and deliberately add specialized platforms only where the primary one creates a measurable penalty — in latency, in cost, or in capability that cannot be closed. The fashionable instinct to consolidate everything onto a single lakehouse or warehouse sounds clean, but it breaks down the moment a workload has physics that the primary platform was never designed for. The opposite instinct — best-of-breed for every workload — creates an integration tax that quietly eats more engineering time than the specialization saves. The real trade-off is not philosophical. It is arithmetic: does the cost of integration between platforms exceed the cost of forcing a workload onto a platform that fits it poorly?

Why does the "one platform" argument keep winning boardroom attention?
Vendor consolidation is easy to model on a slide. Fewer contracts, fewer skills to hire, fewer pipelines to monitor. Snowflake, Databricks, and Google BigQuery have each spent the last three years widening their surface area precisely because this argument resonates with budget holders. When a CFO asks "why are we paying six data vendors?", the consolidation pitch writes itself.

And for a meaningful share of workloads, it is the correct call. Analytical SQL, light machine-learning feature engineering, and BI dashboards can usually live on one modern platform without serious compromise. The problem is that "usually" is doing a lot of heavy lifting in that sentence.

Where does a single platform actually break?
It breaks at the edges — and the edges matter more than they used to.
Real-time event processing. A platform built for batch or micro-batch analytics (Snowflake, BigQuery) will not replace Apache Kafka or Amazon Kinesis for sub-second event routing. Trying to force real-time into a batch-native platform adds latency and cost simultaneously.

Graph workloads. Fraud detection, identity resolution, and supply-chain tracing are graph problems. Running them as SQL joins on a relational warehouse is possible but painfully slow at scale. Neo4j or Amazon Neptune exist because the data structure itself is different.

Unstructured search and retrieval. Vector databases like Pinecone or Weaviate serve embedding-based retrieval for generative-AI applications in ways a warehouse cannot approximate without bolting on external indexes — at which point you have two platforms anyway.

Regulatory isolation. Some industries require that certain data never leaves a specific environment. A single platform that cannot meet that constraint forces a second platform by law, not preference.

How should you decide: consolidation versus specialization?
Use three concrete tests before adding or removing a platform.

The discipline is in the third row. Most teams underestimate integration cost by half. If you cannot name the engineer who will own the sync pipeline between platforms for the next two years, that is a signal to stay consolidated.

What does this trade-off look like in practice?
A large European retailer we studied runs Databricks as its primary analytical platform. When the team needed real-time personalization at the edge, it evaluated whether Databricks Structured Streaming could meet the latency window. It could not — not within cost. The team added Kafka for ingestion and a lightweight feature store, kept Databricks for training and batch scoring, and drew a clear boundary: anything under 200 milliseconds goes through the specialized path, everything else stays on the primary platform. Two platforms, one clear rule for which workload goes where.

Contrast that with a mid-market SaaS company that adopted five specialized databases in two years — document store, graph database, time-series store, warehouse, and a vector database — before any of them held enough data to justify the integration overhead. The engineering team spent more time maintaining connectors than building product features. They eventually collapsed three of the five back onto PostgreSQL with extensions, not because PostgreSQL was better at each job, but because the integration tax exceeded the specialization gain.

What role does demand-led innovation play here?
Platform decisions are often framed as technology choices, but they are demand choices. The workloads that justify a second platform are almost always driven by a new capability the business is trying to offer — real-time fraud alerts, AI-powered search, live supply-chain visibility. When senior technology leaders start from what their own market is demanding rather than from what a vendor is selling, the architecture question answers itself more cleanly: you add a platform when real, forming demand in your market requires a capability your current platform cannot deliver at the right cost or speed. Demand-led innovation keeps the architecture honest.

This is the lens we bring in our work with senior technology leaders. We arrive with a point of view before you hire us — a demand-led read on where the pressure in your market is actually building — so that platform decisions follow real need, not vendor hype cycles.
Frequently asked questions

Platform strategy becomes more defensible when the architectural decision is grounded in evidence about what the business and its market are actually moving toward. The Analyst Layer approach treats these signals as an ongoing account-level intelligence problem, connecting emerging business requirements with the technology capabilities and architectural constraints that will ultimately need to support them. This keeps platform decisions anchored to measurable demand rather than vendor roadmaps or consolidation narratives.

Frequently asked questions

- Should I consolidate all my data onto one platform?
Consolidate by default, but do not treat it as an absolute rule. One platform reduces integration cost, simplifies hiring, and cuts vendor management overhead. Add a second platform only when you can demonstrate that the primary platform imposes a measurable penalty — in latency, cost, or regulatory compliance — that exceeds the cost of integrating a new one.
When is a best-of-breed data architecture worth the complexity? When the workload has fundamentally different data-structure requirements (graph, vector, time-series) and the volume is large enough that the workaround on your primary platform costs more engineering time than maintaining a separate platform would. If the volume is small, an extension or adapter on your existing platform is almost always cheaper.

- How do I calculate the real cost of adding a second data platform?
Add the licensing cost, the engineering hours to build and maintain sync pipelines, the hiring or training cost for a new skill set, and the incident-response overhead when the sync breaks. Most teams account for the first item and forget the other three, which are usually larger.
What is the biggest mistake companies make with data platform strategy? Choosing based on a vendor's roadmap slide instead of a shipping feature. If the capability you need is "coming in Q3," you are making an architecture bet on someone else's execution. Evaluate only what is production-ready today.

- How does demand enablement relate to data platform decisions?
Demand enablement means finding and shaping demand before a deal is obvious. For platform decisions, it means reading where your market's real demand is heading — not where a technology vendor says it is heading — and letting that signal dictate which capabilities your architecture must support. The platform follows the demand, not the other way around.

The short version
Default to one data platform and resist adding others until a specific workload proves the primary platform cannot meet a hard requirement in latency, data-model fit, or regulatory compliance. The real trade-off is not consolidation versus best-of-breed in the abstract — it is whether the integration tax of a second platform is smaller than the penalty of forcing a mismatched workload onto your primary one. Measure both sides honestly, weight integration cost higher than your instinct suggests, and let real, forming demand in your market — not vendor roadmaps — determine when specialization is justified.

Rent or own your AI compute: the honest math

Deb_Ghosh_Analsyt Layer — Mon, 10 Aug 2026 05:33:38 +0000

For most enterprise workloads today, renting AI compute from a hyperscaler is the cheaper, faster, and lower-risk choice. Owning only wins when you have sustained, predictable GPU utilization above roughly 70 percent for at least 18 months — and most organizations are nowhere near that threshold. The honest math favors renting until you can prove, with real workload data, that you have crossed it.
That is the direct answer. The rest of this piece shows the actual trade-offs, names the breakpoints, and tells you exactly when owning starts to make sense.

Why does the rent-vs-own question matter now?
AI infrastructure spending is accelerating faster than most technology leaders expected. NVIDIA's data-center revenue more than tripled year-over-year in its most recent fiscal year, and the three largest cloud providers — AWS, Microsoft Azure, and Google Cloud — have each announced capital expenditure increases north of 50 percent to build out GPU capacity. Senior technology leaders are being asked whether their organizations should follow the same path and invest in their own hardware, or keep paying per-hour for cloud GPU instances.
The question sounds like a procurement decision. It is actually a demand question: do you know enough about your own future AI workload to justify a capital commitment?

What does the cost comparison actually look like?
The numbers shift with every GPU generation, but the structure of the comparison stays the same. Below is a simplified, honest comparison for a single NVIDIA H100 GPU over 24 months — the most common planning horizon we see in enterprise conversations.

The pattern is clear: renting carries lower risk and rewards uncertainty, while owning rewards certainty. The problem is that most organizations are still in the early, experimental phase of AI adoption, where certainty is scarce.

When does owning actually win?
Owning wins under a narrow set of conditions, all of which must be true at the same time:

- Sustained utilization above 70 percent.
Not peak utilization — average utilization across a full quarter. Most enterprise AI workloads are bursty: training runs spike for days, then idle. If your GPUs sit dark half the time, you are paying twice what renting would cost.

- A planning horizon longer than 18 months.
Hardware takes months to procure, rack, and operationalize. If you cannot confidently forecast your workload 18 months out, the capital is at risk before it pays back.

- Data gravity or regulatory constraints.
Some organizations — in healthcare, defense, and financial services — face genuine barriers to moving sensitive training data into a public cloud. This is a real reason to own, but it justifies only the compute tied to those specific workloads, not a blanket infrastructure build.

- In-house operational talent.
Running GPU clusters requires specialized site-reliability and ML-infrastructure engineering. If you need to hire that team from scratch, the fully loaded cost often erases the savings from owning hardware.

Companies like Meta and Tesla own massive GPU fleets because they satisfy all four conditions. Most enterprises satisfy one or two at best.

What mistakes do organizations make most often?
The most common mistake is benchmarking ownership cost against on-demand cloud pricing — the most expensive tier. Reserved instances and committed-use contracts from AWS, Azure, or Google Cloud reduce hourly rates by 40–60 percent. When you compare ownership against a one- or three-year cloud commitment, the break-even utilization threshold moves even higher, often above 80 percent.

The second mistake is ignoring opportunity cost. Capital spent on GPUs is capital not spent on the data engineering, model evaluation, and product work that actually determines whether AI creates value. In the finite-account world we work in every day, we see technology leaders who bought infrastructure before they had a clear demand signal — and then struggled to justify the investment internally.

This is where account-level intelligence becomes important to infrastructure planning. An Analyst Layer perspective treats technology investment as a downstream decision, using evidence about account priorities, emerging initiatives, and workload demand to determine whether a capital commitment is justified. The result is a more disciplined connection between what an organization is likely to need and what it should actually invest in.

How does demand-led innovation change this decision?
The rent-or-own question is a perfect example of why innovation should follow demand, not the other way around. When a technology leader starts from "what GPU should we buy?" they are starting from the technology. When they start from "which business problems have enough sustained, validated demand to justify dedicated infrastructure?" they make a fundamentally different — and better — capital decision.

This is what demand-led innovation looks like in practice: the infrastructure choice is downstream of a clear, evidence-based read on where workload demand is actually forming.

That evidence increasingly comes from a combination of operational telemetry and external B2B market intelligence. B2B market intelligence helps technology leaders connect shifts in enterprise demand, AI adoption, infrastructure investment, regulatory requirements, and competitive behavior to the workloads likely to emerge next. This broader view makes infrastructure planning less about forecasting technology trends in isolation and more about understanding which workloads are likely to become economically significant.

Frequently asked questions

- Is it cheaper to run AI on-premises or in the cloud?

For most organizations, cloud compute is cheaper on a total-cost basis because utilization of owned GPUs rarely exceeds the 70 percent threshold needed to beat reserved cloud pricing. Ownership becomes cheaper only when workloads are large, predictable, and sustained over 18 months or more.
What GPU utilization rate makes owning AI hardware worthwhile? The break-even point typically falls between 65 and 75 percent average utilization over at least 18 months, depending on power costs and staffing. Below that range, you are paying for idle silicon that a cloud provider would have rented to someone else.

- Should startups buy their own GPUs for AI training?

Almost never. Startups face rapidly changing workload profiles, uncertain timelines, and constrained capital. Renting cloud GPU instances preserves cash and lets teams scale up or down as experiments succeed or fail.
What are the hidden costs of owning AI compute? The most commonly underestimated costs are power and cooling upgrades to existing facilities, specialized ML-infrastructure engineering staff, and the depreciation risk of hardware that may be outperformed within 18 months by a new GPU generation.

- When should an enterprise consider a hybrid approach?

A hybrid model — owning a baseline layer of compute for steady-state workloads and bursting into the cloud for peak demand — makes sense once an organization has at least 12 months of workload telemetry proving a stable, high-utilization baseline. Without that data, the "baseline" is a guess.

- How do reserved cloud instances change the rent-vs-own math?

Reserved or committed-use pricing from AWS, Azure, or Google Cloud typically cuts hourly costs by 40–60 percent compared to on-demand rates. This significantly raises the utilization threshold at which ownership becomes cheaper, often pushing it above 80 percent.

The short version
Renting AI compute is the right default for most enterprises today because few organizations have the sustained, predictable GPU utilization — typically above 70 percent over 18 months — needed to make ownership cheaper. Owning wins only when utilization is proven, the planning horizon is long, and the operational talent is already in place. The smartest version of this decision starts not from the hardware but from a demand-led read on where real workload demand is forming — infrastructure follows the demand, not the other way around. Until you have hard utilization data that says otherwise, rent.

SAS vs. Python for banking risk models: a straight answer

Deb_Ghosh_Analsyt Layer — Fri, 07 Aug 2026 05:57:34 +0000

Python is the clear winner for developing new banking risk models, while SAS remains useful strictly for maintaining legacy production engines tied to established regulatory reporting. For modern risk teams, building new credit scorecards and loss models in Python dramatically reduces software licensing costs, accelerates deployment, and integrates seamlessly with cloud data platforms. SAS only holds value where the financial cost of re-validating a decade-old, regulator-approved model under strict governance rules exceeds the savings of switching to open-source software.

In the finite-account world of enterprise banking, technology leaders cannot afford to waste capital on outdated software stack maintenance or misdirected modernization efforts. While traditional software vendors focus on sales enablement once a project is already funded, our focus is on demand enablement—identifying real operational needs early and shaping modern risk architectures while decisions are still forming. Choosing between SAS vs Python banking risk models is not a matter of developer preference; it is a strategic decision about how financial institutions build scalable, compliant risk engines.

Why do banks still rely on SAS for risk models?
For decades, SAS was the default enterprise platform for quantitative finance. Risk modeling teams relied on proprietary procedures like PROC LOGISTIC to build credit scorecards and calculate probability of default. Institutions adopted SAS because it provided a controlled, single-vendor ecosystem where data transformation, statistical calculation, and reporting occurred within a locked environment.

The primary reason SAS remains embedded inside major financial institutions today is not technical superiority, but validated operational history. Banking regulators require institutions to prove that risk models are accurate, stable, and transparent. Guidelines such as Supervisory Regulation 11-7 (SR 11-7)—the primary guidance for model risk management issued by banking supervisors—demand exhaustive documentation, testing, and governance. When a bank operates a SAS risk model that passed regulatory audits years ago, altering the code base creates significant administrative friction.

Replacing operational risk code requires proving to internal audit teams and external regulators that the new code produces identical outputs. Because we arrive with a point of view before you hire us, we observe that legacy risk architectures linger inside major banks simply because the existing models are already approved and compliant.

Where does Python outperform SAS in credit risk modeling?
Python outperforms SAS in speed of innovation, modern machine learning capabilities, and talent availability. In modern banking risk modeling software stacks, open-source libraries like pandas for data processing, scikit-learn for traditional scorecards, and XGBoost for advanced risk classification have become the standard choice for quantitative teams.
When financial institutions pursue demand-led innovation, they require tools that integrate directly with cloud infrastructure and automated deployment pipelines. Python enables quantitative teams to move smoothly from model development to production deployment without requiring manual code translation.

Modernization decisions of this scale require more than technical benchmarking—they require a clear understanding of regulatory pressure, vendor ecosystems, talent availability, and long-term technology strategy. Analyst Layer helps enterprise technology vendors and financial institutions evaluate modernization priorities through analyst-grade market intelligence and evidence-backed strategic research. By combining deep industry analysis with account-specific insights, organizations can make modernization decisions based on verified market realities rather than vendor messaging alone.

Key advantages of Python for banking risk models include:
Cost Elimination: Removing expensive per-core or per-user commercial software license fees.
Advanced Machine Learning: Accessing state-of-the-art algorithms without waiting for vendor software release cycles.
Talent Access: Recruiting from a broad pool of quantitative finance graduates and data engineers trained natively in open-source tools.
Ecosystem Connectivity: Connecting directly with cloud data platforms like Google Cloud and open-source data engines.

To build flexible risk operations, banks must connect analytical insights directly to operational systems. Moving from intelligence to execution requires a flexible programming language that interfaces natively with enterprise cloud environments rather than running inside a proprietary software ecosystem.

How do SAS and Python compare across core risk capabilities?
To evaluate SAS vs Python banking risk models, technology executives must weigh clear trade-offs across governance, deployment speed, and total cost of ownership.

What are the main challenges when migrating risk models from SAS to Python?
When financial institutions begin migrating risk models SAS to Python, technical hurdles center on numerical reconciliation and regulatory governance rather than basic syntax translation.

First, floating-point calculations differ subtly between software platforms. Minor variances in how SAS and Python handle underlying floating-point arithmetic can produce small discrepancies in risk scores across millions of customer accounts. Reconciling these tiny variations is necessary to satisfy internal validation teams and external supervisors.
Second, teams must maintain responsible intelligence throughout the migration process. Responsible intelligence means every mathematical transformation, feature engineering decision, and data lineage step remains completely transparent and auditable. SAS automatically records standard log files during execution; Python teams must intentionally build logging, experiment tracking, and model monitoring into their code pipelines to remain fully compliant with SR 11-7 standards.

When is SAS still the right choice?
Although Python is superior for new development, SAS remains the correct choice when an institution operates a stable, legacy risk model that requires no functional changes and sits inside a fully approved regulatory framework. If a credit risk scorecard or loss-given-default engine is scheduled for retirement within two to three years, the labor cost of rewriting the codebase and re-validating the output under SR 11-7 guidelines will exceed the financial savings of eliminating the SAS license. In those specific scenarios, keeping the existing SAS model in place until system retirement is the most sensible financial decision.

Technology modernization in banking is increasingly driven by high-quality B2B market intelligence rather than isolated product comparisons. B2B market intelligence helps enterprise vendors understand technology adoption trends, regulatory priorities, competitive positioning, and emerging investment areas across the financial services industry. This broader market perspective enables both vendors and banking leaders to prioritize modernization initiatives that align with real enterprise demand instead of short-term technology trends.

Frequently Asked Questions

Is Python accepted by banking regulators for risk modeling?
Yes, regulatory bodies accept Python-based risk models. Regulatory guidance such as SR 11-7 evaluates the rigor of model development, conceptual soundness, validation, and governance rather than the programming language used. As long as a bank provides comprehensive documentation, data lineage, and audit controls, Python models pass regulatory reviews cleanly.

What is the biggest technical challenge when migrating risk models from SAS to Python?
The primary technical challenge is reconciling numerical discrepancies caused by floating-point arithmetic and default package configurations. When scoring large credit portfolios, small variations in data processing between SAS and Python can alter final risk scores, requiring detailed reconciliation audits to satisfy internal model risk management teams.

Does Python handle large banking datasets as effectively as SAS?
Yes, Python handles large banking datasets effectively when configured with distributed processing tools or modern data libraries like PySpark and pandas. While legacy SAS managed memory overhead well on standalone servers, Python integrates far better with modern cloud data platforms to process large enterprise datasets at scale.

How do financial institutions maintain model governance in Python to satisfy SR 11-7?
Institutions maintain governance in Python by integrating version control systems like Git, automated testing frameworks, and centralized model tracking tools. These systems record code changes, dataset versions, and validation results, creating the transparent audit trail required by model risk management regulations.

Which language should quantitative risk teams prioritize for new projects?
Quantitative risk teams should prioritize Python for all new risk modeling projects due to its superior machine learning capabilities, cost efficiency, and wide talent availability. Understanding how to read legacy SAS code remains useful for auditing older scorecards, but new development should take place entirely within Python environments.

The short version
Python is the definitive standard for new banking risk model development, providing unmatched flexibility, modern machine learning capabilities, and access to a broad talent pool without commercial licensing fees. SAS remains relevant exclusively for running legacy production models where the administrative cost of regulatory re-validation outweighs the savings of migrating to open source. For long-term technology strategy, financial institutions should build all new risk scorecards in Python while systematically migrating legacy systems as models reach scheduled refresh cycles.

Why do analyst firms and intent platforms leave a gap in the middle of the funnel?

Deb_Ghosh_Analsyt Layer — Thu, 16 Jul 2026 06:06:35 +0000

Because they answer different questions, and neither answers the one that determines whether a meeting happens.

Analyst firms tell you a category is growing. Intent platforms tell you an account is active. The question that earns a meeting is why this specific buyer, inside this specific account, will engage on this specific problem right now. Nothing in either instrument addresses it.

The gap is structural, not a product deficiency. It follows from what each instrument was built to do.

What analyst firms produce
Analyst coverage operates at the level of the category. Market sizing, vendor comparison, adoption curves, maturity models. The unit of analysis is the market, and the customer is a buyer trying to decide whether to enter it.

This is valuable and it is not account intelligence. A report telling you that model risk tooling is a $2bn market growing at 18% tells a vendor nothing about which of the four hundred banks in scope will buy this year. It cannot, because it never looked at any of them individually. The methodology aggregates.

There is a second thing analyst firms do, which is sometimes confused with the first: analyst relations, the practice of vendors briefing analysts to influence their coverage. This is a marketing function concerned with how a vendor is perceived. It is not an intelligence function and produces no account-level knowledge at all.

What intent platforms produce

Intent platforms operate at the level of the account, which is closer, but they observe only one variable: attention.

Content consumption, aggregated and baselined, produces a surge score. The score says an account is reading more about a topic than it usually does. It does not say what happened, who is accountable, what the gap is, or when the window closes. It says the account is warm.

Every vendor watching the same signal arrives at the same time. The signal is, by construction, not proprietary — it is derived from a publisher network that sells the same observations to everyone. Competing on speed of response to a commodity signal is a poor position.

The gap

Between the category and the surge score sits the thing that actually determines outcomes: the causal chain from a business event, through a named accountability, to a technology implication, inside a window.

This is the mid-funnel. Not top-of-funnel awareness, not bottom-of-funnel procurement. The stage at which a specific person decides whether the vendor understands their problem well enough to be worth twenty minutes.

Analyst firms are above it. Intent platforms are beside it. Nothing occupies it, which is why most enterprise vendors
staff it with human beings doing manual research and calling the output account planning.

Effective B2B intelligence exists precisely in this middle layer. Rather than describing markets or measuring engagement, it explains the causal relationship between business events, executive accountability, technology requirements, and purchasing windows at the individual account level. That shift from descriptive or behavioural data to causal account reasoning is what allows enterprise sales teams to qualify opportunities before demand becomes visible to the rest of the market.

Why the gap persists
Because filling it does not scale in the way software companies want things to scale.
Reasoning from event to accountability to implication requires domain knowledge about the account’s industry, its regulatory environment, its organisational structure. It cannot be derived from a keyword. It can be derived from a person who works in that domain, which is expensive, or from a method that has been calibrated against people who work in that domain, which is what a correction log is for.

The economics only close on a finite universe of accounts. There are perhaps two thousand enterprise technology vendors globally pursuing high-value new-logo deals, and each is pursuing perhaps a few hundred named accounts.

This is small enough to reason about and large enough to be a market. It is not large enough to interest a platform
business predicated on covering fifty million companies, which is why the intent platforms did not build it.

What occupies the gap
An instrument that produces qualification theses rather than scores, corrects them against practitioners, and accumulates the corrections as practitioner-corrected heuristics that transfer to accounts it has never seen.

The output is structured data, not a report — because enterprise buyers build agents on top of data and build nothing on top of a PDF. The value is in continuous refresh, not in the document, which is why the right test of whether such an instrument is working is whether the customer’s own systems query it. A report is consulted once. An instrument
is queried.

This is what analyst-class means in this context, and it is worth separating from the two things it resembles. It is analyst in the sense of a research analyst: someone who forms a thesis, tests it against evidence, and revises. It is not analyst in the sense of the analyst firms, whose unit of analysis is the market. And it is not analyst relations, which is
a communications discipline.

Analyst Layer Account Intelligence is built around this analyst-class model of account intelligence, producing qualification theses that are continuously refined through practitioner feedback instead of static reports or behavioural scores. By combining event-driven research with practitioner-corrected heuristics, the platform generates structured intelligence that can be consumed by sales teams, GTM workflows, and AI agents, enabling account qualification to improve over time rather than becoming obsolete after publication.

The counterargument
The gap description is convenient for anyone selling into it, and that should make you suspicious of it.

A serious objection: perhaps the gap exists because the work cannot be systematised, and every attempt to do so degrades into either a slower analyst firm or a worse intent platform. Manual research by a good rep genuinely does produce qualification theses, and it is not obvious that a method can match a smart human who has covered the same industry for fifteen years.

The honest answer is that the method does not need to match the best rep. It needs to make the median rep produce what the best rep produces, and to retain that reasoning when the best rep leaves. Whether that is achievable is an empirical question, and the evidence is the correction log: if corrections stop being surprising, the heuristics haveconverged. If they never stop, the sceptics were right.

A second objection: analyst firms could move down into this gap, and intent platforms could move up. Both have tried. The failures are instructive — analyst firms cannot produce account-specific claims without abandoning the impartiality their business depends on, and intent platforms cannot produce causal reasoning from observational
data they collect passively. The gap is defended by the business models on either side of it.

Why Your Best Accounts Are Still Losing. The Fit vs. Forcing Problem in Enterprise Sales

Deb_Ghosh_Analsyt Layer — Sat, 27 Jun 2026 08:40:54 +0000

Most enterprise sales organizations have a systematic win rate problem that is not primarily a sales execution problem. The pipeline contains a mix of deals: genuine fits, where the solution addresses the account's real problem with real capability; marginal fits, where the solution is adequate but not superior to alternatives; and forcing situations, where the deal could be won with enough effort but the underlying fit is not there. Execution quality affects how many deals close in each category. It does not change which category a deal is in.

The uncomfortable truth for many enterprise sales organizations is that a significant portion of their sales cycle time is invested in forcing situations — deals that the team is working hard to close, where the effort required to win is disproportionate to the value of having won, and where post-close retention and expansion are materially weaker than in the genuine fit deals.

The fix is not better closing skills. The fix is fit-discrimination — the capability to identify genuine fits early in the pipeline, invest in them with full force, and deprioritize forcing situations before they consume the resources that the genuine fits deserve.

What Genuine Fit Actually Means at the Account Level
Category-level market research — including the analyst reports and competitive comparisons that sales teams regularly use — is built around population-level fit: which vendor is generally regarded as strong for this use case category, which capabilities are considered table stakes, which vendors are gaining or losing ground across the market. This is useful for orienting a product strategy. It is almost useless for determining whether a specific solution genuinely fits a specific account's actual problem.

Genuine fit at the account level requires asking a different set of questions. Not "is our solution strong in this category" but "does our specific capability address this account's specific version of the problem, in their specific technical environment, with their specific team and timeline constraints?" The category answer and the account-level answer can be radically different.

An account in the financial services sector evaluating fraud detection capabilities might have a problem that is specifically about real-time decisioning at sub-second latency on streaming transaction data. A solution that is excellent at batch-mode fraud analytics is genuinely strong in the category. It is not a genuine fit for this account's specific problem. A sales team armed with category-level intelligence will see a target account in an industry where their solution is competitive. A sales team armed with account-level fit intelligence will see whether the specific version of the problem the account has is one the solution genuinely addresses.

The Forcing Tax: What It Costs to Win the Wrong Deals
There is a compounding cost to winning forcing situations that enterprise sales organizations rarely measure directly but always feel.

The deal cost.
Forcing situations are expensive to close. They require more cycles, more discounting, more executive involvement, more solution engineering time, and more post-sale transition work than genuine fits. The acquisition cost per forced deal is substantially higher than for a genuine fit deal in the same market.

The retention cost.
A customer who bought because they were persuaded, not because the solution was clearly the best fit for their actual problem, is a customer who is continuously exposed to re-evaluation. They do not have the deep conviction that makes a customer an advocate and an expansion opportunity. They have the residual uncertainty of a buyer who was sold, not convinced.

The reference cost.
Forced deals produce weaker references — at best, customers who will confirm the product works, rather than customers who will actively advocate that it is the best solution for a specific problem. In enterprise technology sales, where references from comparable organizations are a primary input to buyer confidence, the difference between a lukewarm reference and a strong advocate is measurable in deal velocity and win rate.

The opportunity cost.
Every resource cycle invested in a forcing situation is a cycle not invested in a genuine fit that might have been identified and advanced in the same window. This is the least visible and most significant cost: the genuine wins that did not happen because the team was busy forcing the wrong deals.

How Fit-Discrimination Changes the Pipeline Equation
A sales organization with strong fit-discrimination capability does not simply have a higher win rate on the same pipeline. It has a different pipeline — one that is smaller in number, higher in genuine propensity to close, and substantially better in post-close performance.

The pipeline change happens in two places. Upstream, in how in-market accounts are identified:Modern buying signals are also becoming more contextual than behavioral. This shift is explored further in The New Observability Intents of 2026, where we examine how enterprise buying intent increasingly emerges from account-specific operational triggers rather than traditional digital engagement metrics. Fit-discrimination and intent intelligence become most valuable when used together. A fit-discrimination capability applied to account targeting means the shortlist of accounts worth pursuing is genuinely a shortlist of accounts where the solution fits the actual problem, not a list of accounts where the market category overlaps. Downstream, in how deals are qualified as they enter the active pipeline: a fit-discrimination capability applied to qualification means the team makes the in/out decision earlier and with better information, so forcing situations are deprioritized before they consume significant resources.

Even when an account is identified as a genuine fit, success depends on engaging the buying organization in the right sequence. As we discuss in The Cascade Method, the path through the buying committee often determines whether a technically strong opportunity becomes a commercial win. Account qualification and buyer engagement are complementary disciplines—one identifies where to invest, while the other determines how to execute.

The discipline Analyst Layer applies to this — what the Calibration standard and the Use-Case Repository enable — is a judgment layer that grounds fit-discrimination in comparable situations rather than making the call from scratch. When an account's specific problem has been seen before in the repository of prior engagements, the judgment about fit is faster, more confident, and more accurate. Pattern intelligence compounds.

This capability is further strengthened through the Analyst Layer Tech methodology, which combines structured use-case intelligence, primary account research, and pattern recognition into a repeatable decision framework. Instead of relying on intuition alone, sales and product teams can evaluate account fit against validated engagement patterns, enabling more consistent qualification and better allocation of resources.

The fit-discrimination problem is closely connected to the build-versus-buy intelligence problem — both require account-level, use-case-specific assessment rather than category-level analysis. For the build-vs-buy parallel, see our companion article.

The Intelligence Infrastructure for Fit-Discrimination
This is where B2B intelligence becomes an operational capability rather than simply a research function. Effective B2B intelligence combines primary account research, organizational mapping, technology landscape analysis, buying committee intelligence, competitive context, and historical engagement patterns into a single decision framework. Rather than supplying more account data, it helps commercial teams determine whether a solution genuinely fits an organization's current priorities, technical environment, and business objectives before significant sales resources are committed. In practice, it shifts qualification from intuition to evidence, enabling more consistent pipeline decisions and stronger long-term win rates.
Strong fit-discrimination capability requires investment in intelligence infrastructure that most enterprise sales organizations do not currently have. Three components are essential.

A use-case library. The ability to characterize, with precision, the specific versions of the problem the solution genuinely addresses, and the versions where the fit is weaker or absent. This requires structured accumulation of experience across engagements — what the genuine fits look like at the account level, what the marginal fits look like, and what the forcing situations look like — and active reference to that pattern library in qualification decisions.

Primary account intelligence. The ability to understand, at the individual account level, the specific version of the problem the account has: not the category problem, not the industry version, but the account's actual current configuration and requirement. This requires primary account research and analyst relations intelligence rather than relying solely on data platform signals.
An honest out-mechanism. The cultural and organizational permission to deprioritize an account that is a forcing situation, even when the account is large, the relationship is warm, and the team believes they can close it with enough effort. The hardest part of fit-discrimination is not the diagnosis; it is the decision to act on it.

FAQ:

Q: What is the "fit vs. forcing" problem?
A: Fit vs. forcing describes three deal types in enterprise pipelines: genuine fits (solution addresses the account's exact problem), marginal fits (solution is adequate but not differentiated), and forcing situations (wins possible only with disproportionate effort). High win-rate teams differentiate early to focus resources on genuine fits rather than forcing deals that consume time and budget.

Q: Why aren't execution improvements enough?
A: Execution quality raises close rates within each deal category but doesn't change a deal's category. Improving closing skills helps marginal and genuine-fit deals but cannot convert forcing situations into genuine fits — only better fit-discrimination can.

Q: How do forcing situations harm my business?
A: Forcing deals raise acquisition costs (more cycles, discounts, exec time), reduce retention and expansion (buyers lack conviction), weaken references, and create opportunity cost by diverting resources away from genuine-fit accounts that would generate stronger outcomes.

Q: What does "genuine fit" mean at the account level?
A: Genuine fit means the solution maps to the account's specific problem, technical environment, team, and timeline — not just the market-level category. Account-level fit asks whether your capability solves this customer's precise version of the problem, such as real-time sub-second fraud decisioning versus batch analytics.

Q: How does fit-discrimination change pipeline composition?
A: Fit-discrimination narrows the pipeline to fewer, higher-propensity deals and accelerates post-close success. Upstream targeting selects accounts that match account-level use cases; downstream qualification weeds out forcing situations early, yielding stronger win rates and better referenceability.

Q: What infrastructure is required for fit-discrimination?
A: Build three pillars: a use-case library that catalogs specific problem variants and prior outcomes; primary account intelligence gathered via direct research and conversations; and an honest out-mechanism — organizational permission to deprioritize forcing deals even when politically difficult.

Q: How do I build a use-case library?
A: Capture structured data from past engagements: problem variant, technical constraints, buyer stakeholders, deal motions, outcomes (win/loss, retention), and reference strength. Tag patterns and make them searchable so sellers can compare an active account to prior, clearly labeled matches.

Q: What signals indicate a forcing situation early?
A: Early warning signs include unclear or shifting problem definitions, heavy emphasis on custom roadmap promises, repeated discounting requests, multiple stakeholder misalignment, and requirement patterns that don't match known successful use-case profiles in your repository.

Q: How do I convince leadership to deprioritize forcing deals?
A: Quantify the cost: estimate extra seller hours, discount impact, and lost opportunity by modeling resources diverted from genuine-fit deals. Present historical outcomes for forcing wins (lower renewal/expansion rates, weak references) to show long-term revenue erosion.

Q: Can CRM and analytics tools solve fit-discrimination?
A: Tools help, but only when fed structured use-case labels and primary intelligence. CRM signals without account-level context tend to reflect category-level similarity. Integrate qualitative research, use-case taxonomy, and decision rules into tooling to operationalize fit judgments.