TORONTO, ON, CANADA – April 8, 2026 – Centrilogic, a global provider of IT transformation solutions, today announced it has earned the Data Analytics on Microsoft Azure Specialization, further validating the company’s expertise in planning, designing, and delivering advanced analytics on Microsoft Azure.  

The Data Analytics on Microsoft Azure Specialization recognizes partners that demonstrate extensive capabilities in delivering end-to-end data analytics solutions, from data strategy and architecture design through implementation, optimization, and ongoing support.  

To earn this specialization, Centrilogic met Microsoft’s highest standards for analytics service delivery, governance, security, and support. Centrilogic also demonstrated proven customer success, strong technical capabilities, and mature delivery practices across Azure data and analytics services, including modern data platforms, advanced analytics, and AI-driven insights.  

This recognition also highlights Centrilogic’s ability to help mid-market and enterprise customers maximize the value of their data assets and build secure, scalable, enterprise-grade analytics platforms that enable transformative insights and better business decision-making.  

“Earning the Data Analytics on Microsoft Azure Specialization underscores our focus on helping organizations build strong, trusted data foundations that enable better decision-making at scale,” said Doug Tracy, CEO of Centrilogic. “As data and analytics become central to AI adoption and enterprise strategy, organizations need partners who can design, govern, and operationalize analytics platforms that deliver real business insights and benefits. This recognition reinforces our ability to help customers move from data complexity to clarity with confidence.”  

Centrilogic and Microsoft have built a trusted partnership spanning more than 15 years, working together to help midmarket and enterprise organizations modernize data platforms, accelerate analytics adoption, and enable AI-driven decision-making across the Microsoft cloud ecosystem. Backed by a team of senior Microsoft-certified experts, Centrilogic delivers comprehensive solutions across application modernization, cloud engineering, data & AI, security, DevOps, and managed services.  

About Centrilogic:   

Centrilogic is a global provider of IT transformation solutions that empower organizations to realize their full digital potential. Armed with capabilities that span the stack – including multi-cloud management, application innovation, data & AI, and IT advisory – Centrilogic delivers resilient end-to-end digital solutions that help companies reshape the role of their technology platforms as business-driving assets. With regional headquarters in Canada, USA, and India, Centrilogic delivers solutions to innovative companies worldwide. For more information, visit www.centrilogic.com.   

The post Centrilogic Achieves the Data Analytics on Microsoft Azure Specialization  appeared first on Centrilogic.

How Do I Run AI Workloads When My Regulator Says the Data Can’t Leave the Country?

I often find myself in conversations with Canadian executives who are wrestling with the same question: “We want to deploy AI. Our regulator says the data stays in Canada. Now what?”

It’s a fair question. And it’s one that most of the public conversation around AI is failing to answer clearly.

The vendor keynotes talk about transformation. The compliance team talks about risk. The board wants both. The people in the middle, the Architects, CIOs, VPs of IT, are left trying to reconcile two mandates that feel like they’re on a collision course.

I lead an architecture team that designs and delivers cloud and AI environments for regulated Canadian organizations. We’re not theorizing about what’s possible. We’re building what works today, within the constraints that actually exist. This is the ground-level view.

“Data Can’t Leave the Country” Is More Complicated Than It Sounds

The first thing executives need to understand is that “Canadian data residency” isn’t a single rule. It’s a stack of overlapping obligations that vary by province, sector, and data classification.

At the federal level, PIPEDA doesn’t actually mandate that data stay in Canada. It requires organizations to inform individuals about cross-border transfers and obtain meaningful consent. That’s an important distinction, but it’s also just the baseline.

The real teeth come from the provinces and sector regulators. Quebec’s Law 25 imposes the strictest regime in the country: any transfer of personal information outside the province requires a privacy impact assessment, and the destination jurisdiction must offer protection “essentially equivalent” to Quebec law. The penalties, up to $10 million or 2% of worldwide revenue, are not theoretical. Ontario’s PHIPA is widely believed to mandate that personal health information stay in Canada, but the reality is more nuanced. PHIPA restricts unconsented disclosures to independent third parties outside the province, not the hosting of data by a cloud provider acting as an agent under contract. A hospital using Azure to run an AI diagnostic model isn’t “disclosing” data to Microsoft in the PHIPA sense, provided the right contractual safeguards are in place. The distinction matters because it opens architectural options that many healthcare organizations assume are off the table. Alberta’s PIPA adds yet another layer.

Then there are the sector regulators. OSFI’s Guideline B-13 (Technology and Cyber Risk Management) is often cited as requiring in-country processing, but it’s actually a principles-based risk management framework, not a geographic embargo. It requires rigorous oversight of third-party vendors, robust incident reporting, and comprehensive risk documentation. Many financial institutions choose to localize data processing because it simplifies their risk posture, but B-13 itself doesn’t forbid foreign processing if the controls are in place. What it does mean is that if you process data outside Canada, you own the burden of proving you’ve managed every associated risk.

Separately, OSFI finalized the updated Guideline E-23 (Model Risk Management) in late 2025, with a mandatory effective date of May 1, 2027. This is the one that changes the game for AI. E-23 now explicitly covers AI and machine learning systems, requiring enterprise-wide model identification, risk assessment, deployment controls, continuous monitoring, and formal decommissioning processes. If you’re in financial services, your AI models will need the same governance rigor as your credit risk models. This isn’t guidance. It’s regulatory expectation with a hard deadline.

The point is: when a regulator says “the data stays here,” the specific meaning depends entirely on who your regulator is, what province you’re in, and what kind of data you’re handling. Most organizations underestimate this complexity until they’re already deep into an AI initiative.

PBMM: The Standard That Gates Public Sector, and Increasingly Everything Else

If you work with the Canadian federal government, you already know Protected B, Medium Integrity, Medium Availability (PBMM). It’s the cloud security standard defined in ITSG-33 and evolved into the CCCS Medium Cloud Profile. It’s the bar your cloud environment has to clear to handle non-classified government information.

What’s changed is that PBMM is no longer just a public sector concern. We see it referenced in provincial procurement, in RFPs from regulated private sector organizations, and as a proxy standard for “serious about security” in industries that don’t have their own cloud certification framework.

The major cloud providers have all invested in PBMM assessments. Azure was one of the first to qualify. AWS reports 162 services assessed against CCCS Medium requirements as of late 2025. Google Cloud is approved for Protected B Medium and High Value Asset workloads. IBM maintains PBMM in their Toronto and Montreal facilities.

But here’s the gap that matters: PBMM certification for AI-specific services (Azure OpenAI, Cognitive Services, the inference endpoints you actually need) is not explicitly published in the same way that general IaaS and PaaS services are. General cloud PBMM is not the same as AI service PBMM. This distinction is where deals stall, and projects get delayed. If you’re building an AI workload for a regulated environment, you need to understand exactly which services have been assessed and which are running on assumption.

What You Can Actually Run Today

Let me be direct about the current state, because I think the market needs more honesty here and less aspiration.

Azure OpenAI offers models in Canada Central and Canada East, but model availability varies significantly by deployment type. Established models like GPT-4 and GPT-4o support standard regional deployments with strict data residency: both inference and data processing happen exclusively within Canadian data centres. However, newer frontier models (the GPT-4.1 series, advanced reasoning models like o1 and o3) are currently unavailable for standard regional deployment in Canada Central. To access these, architects are pushed toward “Global Standard” or “Data Zone” deployment types, which dynamically route inference across Azure’s global infrastructure, fundamentally breaking strict data residency. This is a critical distinction: you can run production AI in-region today, but the most capable models may require you to choose between cognitive performance and geographic isolation.

AWS Bedrock offers foundation model access from ca-central-1 (Toronto) and ca-west-1 (Calgary), including Anthropic’s Claude models. But there’s a critical nuance: AWS achieves this through cross-region inference. Your data at rest (logs, knowledge bases, stored configurations) stays in Canada, but the inference processing itself may route to US regions. For workloads where the regulator cares about where compute happens, not just where data sits, this distinction matters. You need to understand whether your compliance framework draws the line at data residency or processing residency.

Anthropic’s Claude API (direct, not through a cloud provider) currently processes all data in the United States. There is no Canadian data residency option. Anthropic has introduced EU data residency for API customers, which suggests regional expansion is on the roadmap, but nothing is announced for Canada. For organizations that need Claude’s capabilities within Canadian borders today, the path runs through Bedrock, with the cross-region inference caveat above.

Google Vertex AI offers Claude and Gemini models in the Toronto region, with regional endpoints that provide guaranteed data routing through specific geographic regions. This adds another option, though at a 10% pricing premium over global endpoints.

The honest summary: you can run production AI inference in Canada today, with real data residency guarantees, if you choose the right platform, the right models, and the right deployment configuration. But the most capable frontier models often require global routing that breaks strict residency, and the managed orchestration services are either deprecated or unavailable in-country. The gap is narrowing fast, but if you’re making architecture decisions right now, make them based on what’s certified and available, not what’s on a roadmap.

The Architecture Decisions That Actually Matter

These are the conversations that separate a successful sovereign AI deployment from one that stalls in procurement review.

Region selection is a governance decision, not a performance decision. Lock Canada Central as your AI compute region. Document the rationale. Make the decision auditable. This sounds obvious, but I’ve seen organizations leave region selection to a developer’s default configuration and then scramble to explain it to an auditor six months later.

Classify your data before you select your models. Know what’s Protected B, what’s sensitive personal information, what’s proprietary but not regulated, and what’s public. Then map each classification to the services that are certified to handle it. Most organizations want to start with the model and work backward to the data. That’s exactly the wrong order for regulated environments.

Understand that “available in Canada” means different things on different platforms. Azure OpenAI in Canada Central runs inference in-region for supported models, but frontier models may require Global routing that breaks residency guarantees. Bedrock cross-region inference from ca-central-1 keeps data at rest in Canada but may process inference in the US. Anthropic’s direct API runs entirely in the US. These are not equivalent from a compliance perspective, even though all three give you access to powerful models. Your architecture needs to reflect the actual data flow, not the marketing summary.

Stay current on platform deprecations. If you’ve been planning agent-style orchestration around Azure OpenAI’s Assistants API, stop. Microsoft has officially deprecated the Assistants API, with complete retirement scheduled for August 26, 2026. It has been replaced by the Microsoft Foundry Agents Service, a modernized framework with stronger observability, version control, and enterprise governance. Any organization building custom middleware while waiting for Assistants to land in Canada is investing in a dead end. Architects should evaluate Foundry Agents now and plan migration paths for any existing Assistants-based work. More broadly, this is a reminder that the AI platform landscape is moving fast enough to invalidate architectural assumptions within months. Build modularly, stay close to the deprecation notices, and don’t bet your architecture on a single service remaining stable.

Contractual data residency is not the same as technical data residency. Azure’s contractual commitments around Canadian data processing are strong. But your architecture has to enforce them. Private Endpoints, Azure Policy definitions that deny non-Canadian resource creation, network security groups, diagnostic settings that keep logs in-region: these are the controls your auditor will actually ask about. A contract tells your regulator you intend to keep data in Canada. Your technical controls prove you did.

Treat model risk management as a first-class governance discipline. This one is specifically for financial services today, but it’s heading everywhere. OSFI E-23 takes full effect May 1, 2027, and it covers AI/ML explicitly. Model identification, risk assessment, deployment controls, performance monitoring, bias testing, explainability, and formal decommissioning are all in scope. Build these into your AI platform from day one. Retrofitting governance to satisfy an OSFI audit after the fact will be far more expensive and disruptive than doing it right up front.

The underlying principle: sovereign AI is not a product you buy. It’s an architecture you design. The decisions that matter most are the unglamorous ones: region locks, data classification, policy enforcement, model governance.

The CLOUD Act – Elephant in the Room

I’d be doing a disservice if I didn’t address this directly, because every informed client raises it and too many advisors dodge it.

The U.S. CLOUD Act gives American authorities the legal right to compel U.S.-headquartered companies to produce data in their custody, regardless of where that data is physically stored. Microsoft, AWS, Google, and Anthropic are all U.S.-headquartered. Your data can be sitting in a Toronto data centre, running on Azure, with a Canadian data residency contract, and the U.S. government can still, in principle, issue a lawful demand for it.

Microsoft has responded with a five-point Digital Sovereignty Plan: a Threat Intelligence Hub in Ottawa, expanded confidential computing capabilities, enhanced data residency commitments, sovereign landing zone architectures, and contractual protections designed to keep Canadian data under Canadian legal authority. These are meaningful steps. AWS and Google have made similar commitments around data sovereignty, though with different implementation approaches.

Here’s what honest advisors tell their clients: the combination of Canadian data residency, encryption at rest and in transit, customer-managed keys, access controls, and contractual commitments significantly reduces the practical risk. For the vast majority of regulated workloads, this combination meets the bar that Canadian regulators are setting. For a narrow set of the highest-sensitivity workloads (think national security, certain government classified environments), it may not, and those organizations may need sovereign cloud options or on-premises deployments.

The pragmatic position: don’t pretend the CLOUD Act doesn’t exist. Don’t pretend it blocks everything, either. Understand where your data sits on the sensitivity spectrum and architect to the actual risk, not the headline.

What the Next 12 Months Look Like

The investment wave is real. Microsoft’s $7.5 billion. The federal government’s $925 million. The AI Compute Challenge calling for 100+ megawatt sovereign data centres. The University of Toronto receiving $42.5 million for AI compute infrastructure. This isn’t speculative. It’s funded and in motion.

But there are things the money doesn’t solve yet. Canada still has no comprehensive AI legislation. Bill C-27 and AIDA died when Parliament dissolved in 2025, and while a successor is expected, the timing is uncertain. In the meantime, sector regulators (OSFI, Health Canada, Transport Canada) are filling the gap with guidance that has practical regulatory weight even without a new law.

The AI platform landscape is also converging on Canada. Anthropic is expanding its regional data residency options (EU is live, other regions are expected to follow). AWS is broadening Bedrock’s in-region capabilities. Microsoft is pouring infrastructure dollars into Canadian capacity that comes online in H2 2026. Cohere, a Canadian-founded AI company, has models available on Azure, adding a sovereign-origin option to the platform.

What this means for executives making decisions today: the infrastructure is coming, the regulatory framework is converging, and the service gaps are closing. But you should not architect for next year’s availability. Build on what’s certified and available now. Design your governance framework so it can absorb new services and new regulations as they arrive. The organizations moving now, with proper controls, will have 12 to 18 months of operational learning and institutional knowledge that their competitors won’t.

Waiting for perfect regulatory clarity before deploying AI in a regulated Canadian environment means waiting indefinitely. The organizations that will lead didn’t wait for perfection. They moved with governance.

Reframing the Question

The question I started with (“How do I run AI workloads when my regulator says the data can’t leave the country?”) is actually the wrong question, or at least an incomplete one.

The better question is: How do I architect AI workloads that satisfy my regulator, my board, and my users, simultaneously?

The answer isn’t a single product or a single certification. It’s an architecture designed with intention: the right region, the right data classifications, the right technical controls, the right governance model, and an honest assessment of what’s certified today versus what’s on someone’s roadmap.

The infrastructure investment is happening. The regulatory frameworks are converging. The AI services are landing in Canadian regions. The window for competitive advantage is open right now, for the organizations willing to build thoughtfully rather than wait for someone else to make it easy.

I’d like to hear what you’re seeing in your own environments. If you’re navigating sovereign AI in a regulated Canadian industry, what’s working? Where are you stuck? The more practitioners share what they’re learning, the faster this market matures for everyone.

The post How Do I Run AI Workloads When My Regulator Says the Data Can’t Leave the Country? appeared first on Centrilogic.

TORONTO, ON, CANADA – March 31, 2026 – Centrilogic, a global provider of IT transformation solutions, today announced it has earned the Agentic DevOps with Microsoft Azure and GitHub Specialization, validating the company’s ability to help mid-market and enterprise organizations establish secure, modern software development practices by applying DevOps principles and using GitHub and Azure solutions.

This specialization recognizes Microsoft partners that demonstrate deep expertise in delivering end‑to‑end agentic DevOps capabilities, spanning initial assessment and solution design through pilot, implementation, and post‑implementation support. Achieving this designation confirms that Centrilogic has adopted robust, repeatable processes that support customer success across all phases of agentic DevOps.

Earning this specialization places Centrilogic among a select group of Microsoft partners that meet Microsoft’s stringent technical, performance, and audit requirements. It reflects proven customer success, strong technical capabilities, and mature delivery practices aligned with Microsoft’s Azure DevOps and GitHub solutions.

“Achieving the Agentic DevOps with Microsoft Azure and GitHub Specialization reflects our continued investment in modern engineering practices and our commitment to helping customers build, deploy, and operate software securely and at scale,” said Doug Tracy, CEO of Centrilogic. “As organizations look to adopt agentic and AI‑driven development models, DevOps discipline becomes even more critical. This recognition reinforces our ability to guide customers through that journey with confidence.”

Centrilogic and Microsoft have built a trusted partnership spanning more than 15 years, working together to help mid‑market and enterprise organizations modernize applications, improve developer productivity, and accelerate innovation across the Microsoft cloud ecosystem. Backed by a team of senior Microsoft‑certified experts, Centrilogic delivers comprehensive solutions across application modernization, cloud engineering, DevOps, data & AI, security, and managed services.

About Centrilogic:

Centrilogic is a global provider of IT transformation solutions that empower organizations to realize their full digital potential. Armed with capabilities that span the stack – including multi-cloud management, application innovation, data & AI, and IT advisory – Centrilogic delivers resilient end-to-end digital solutions that help companies reshape the role of their technology platforms as business-driving assets. With regional headquarters in Canada, USA, and India, Centrilogic delivers solutions to innovative companies worldwide. For more information, visit www.centrilogic.com.

The post Centrilogic Achieves Agentic DevOps with Microsoft Azure and GitHub Specialization appeared first on Centrilogic.

This is the 3rd post in a 4 part series. To read part 1 titled: Agentic AI Is Coming to the Enterprise — Are You Ready? visit https://www.centrilogic.com/agentic-ai-enterprise-readiness/

To read part 2, titled: Agentic AI is Coming to the Enterprise: – Threat Assessment, visit https://www.centrilogic.com/agentic-ai-enterprise-risks.

This is the third in a four-part series about operations and security in the agentic AI world. It is intended for informational purposes only. Please engage an AI security professional before implementing agentic AI.

In the first two parts of this series, we explored why agentic AI represents a fundamentally new category of enterprise risk, and what the threat landscape actually looks like for leaders who are preparing to deploy autonomous systems. Now it’s time to get practical.

The good news: trustworthy agentic AI is absolutely achievable. The catch: you can’t bolt security on after the fact. With agentic systems, safety must be designed in from the very beginning — before the first line of code is written.

Here is a practical blueprint for doing exactly that.

1. Start With “Security by Design”

Most technology initiatives begin with capability. Agentic AI requires flipping that script. Security isn’t a feature you add at the end. It’s the foundation everything else is built on. Three principles should guide every agentic architecture from day one:

• Defense-in-depth. Layer your controls so that a single failure doesn’t compromise the entire system.
• Least privilege. Give agents the minimum permissions needed to do their job — nothing more.
• Zero trust. Validate every action an agent takes, even within your own environment. Assume nothing is inherently safe.

These aren’t abstract ideals. They are practical design decisions that prevent oversights from becoming liabilities.

2. Threat Model the Agent in Business Language

Threat modeling sounds like an IT exercise. It doesn’t have to be. Business leaders can and should participate in this process. The questions are straightforward:

• What could go wrong with this agent? ·
• Who could misuse it — internally or externally?
• What is the worst-case scenario for this workflow?
• What data might be exposed, altered, or corrupted?

Once you’ve answered those questions, translate the risks into concrete design requirements:

• Should certain actions require human approval before the agent proceeds?
• Should the agent be sandboxed from sensitive systems?
• What should never happen under any circumstances?
• What must be logged for auditing and accountability?

This conversation produces a practical security roadmap for the engineering team and keeps business intent at the center of the design.

3. Define Agency vs. Autonomy

This is one of the most powerful mental models for enterprise AI adoption, and one of the least understood.

Agency is what the agent is allowed to do — reading data, writing records, sending communications, triggering workflows.

Autonomy is when it’s allowed to act without human oversight — never, sometimes, always, or only within specific conditions.

These two dimensions can be mixed and matched deliberately:

• High agency, low autonomy — the agent can do a lot, but a human approves every significant action.
• Low agency, high autonomy — the agent acts freely, but within a very narrow scope.
• High agency, high autonomy — powerful, but rare and high-risk. Reserved for mature, well-monitored systems.
• Low agency, low autonomy — common in pilots. Safe starting point for most organizations.

Defining this operational envelope gives leaders precise control over what an agent can do and when. It also makes the conversation between business and technical teams dramatically more productive.

4. Build in Observability and Control

Agentic AI should never be a black box. Your architecture needs to answer these questions at any point in time:

• Why did the agent take that action?
• What sequence of decisions led to this outcome?
• Who or what authorized it?

That means building in:

Rationale logging — a record of why the agent acted, not just what it did.

Traceability— a full audit trail of the decision chain.

Circuit breakers — automated mechanisms that halt agent activity when behavior falls outside acceptable boundaries.

Human review workflows — escalation paths for actions with significant business, financial, or regulatory impact.

These aren’t overhead. They are the mechanisms that make agentic AI trustworthy to executives, auditors, regulators, and the customers you serve.

5. Align With Industry Frameworks

There are several established frameworks that support responsible agentic AI design. Use them as tools, not textbooks:

NIST AI RMF – excellent for governance structure and risk context mapping.

ISO/IEC 42001 – provides an organizational framework for AI management systems.

CSA MAESTRO – purpose-built for threat modeling AI and multi-agent systems.

OWASP LLM Guidelines – critical for addressing prompt injection, output handling, and integration security.

Together, these guides give your organization a holistic, defensible approach to AI Threat mitigation that will hold up to audit and legal scrutiny both internally and externally.

6. Produce Deliverables Your Organization Can Actually Use

By the end of the design phase, your team should be able to hand the following to engineering, operations, legal, and risk:

• System architecture diagrams with security components clearly identified
• A threat model with specific, actionable mitigations
• Defined agency and autonomy levels for each agent
• An accountability model that answers “who owns this agent’s actions?”
• Logging and audit requirements
• Guardrail policies and decision thresholds
• Clear boundaries on what the agent is allowed and not allowed to do

This isn’t documentation for its own sake. It’s the difference between an agentic system that scales confidently and one that generates a crisis the moment something unexpected happens.

The Takeaway

Enterprises that design agentic AI correctly will be positioned to adopt the technology safely, quickly, and with a meaningful competitive advantage. Those who rush in without a blueprint risk failures that are operational, financial, and reputational — and increasingly public.

The design phase is where trust is either built or forfeited. It is worth the investment.

In the final article of this series, we will explore how to operate, monitor, and govern agentic AI in real time with practices that keep autonomous systems aligned, auditable, and effective long after they go live.

Remember, the easy part of agentic AI is building it. The hard part is making it a trustworthy tool for your business.

The post Agentic AI Is Coming to the Enterprise – How to Design and Build Trustworthy Agentic AI appeared first on Centrilogic.

Azure DevOps Love

New features and enhancements are coming to Azure DevOps all the time, and it makes me so happy.

Here are a few that just dropped this month. They are so new you may not see them in your instance of Azure DevOps yet, as they roll out gradually. Actually some of the images below are taken from release notes because the feature has not shown up in my Azure DevOps yet. 🙂

Azure Boards — Condensed card display.

I love this new feature. Adding information to the cards in on your Kanban board can be so useful. However it’s easy to get carried away and the card ends up very big.

A new toggle switch has been added called Collapse card fields. Highlighted in the image below, and turned off.

Click that button and all the extra info is hidden and you just see the work item with it’s ID and description.

Azure Repos — Auto-complete pull requests by default

I have always loved the auto-complete feature in Azure Repos. For those not familiar, you can create a PR and set it to auto-complete. Which means after all the checks have passed and it’s been approved by reviewers, the PR will be automatically closed and merged. No need for you to come back later and merge the PR.

Well now you can make this the default setting either for the whole project or for each Repo individually.

When this is enabled, every new PR will automatically have Set auto-complete turned on. When disabled, new PRs will start with Set auto-complete turned off, and authors can choose to enable it manually.

Azure Test Plans — Exploratory Testing

As you may have read in past posts, I love Azure Test Plans. I also love the Exploratory Testing tool. Microsoft recently updated the test run user interface, it was previously terrible and ignored for too long. It’s much better now, perhaps a post about that is required. Well the exploratory Test runs was also terrible, as it was just tucked away in with test runs.

As of this month it has it’s own place of honour in the main navigation bar under Test Plans.

The post New Features in Azure DevOps – March 2026 appeared first on Centrilogic.

This is the 2nd post in a 4 part series, to read part 1, visit: https://www.centrilogic.com/agentic-ai-enterprise-readiness.

Agentic AI is Coming to the Enterprise: Part 2 – Threat Assessment

The post Agentic AI is Coming to the Enterprise: Part 2 – Threat Assessment appeared first on Centrilogic.

To read part 2, titled: Agentic AI is Coming to the Enterprise: Part 2 – Threat Assessment, visit https://www.centrilogic.com/agentic-ai-enterprise-risks.

Agentic AI Is Coming to the Enterprise — Are You Ready?

This is the first in a four-part series about operations and security in the agentic AI world. It is intended for informational purposes only. Please engage an AI professional before implementing agentic AI.

In case you looked away for a moment, you might not have noticed that agentic AI is no longer a far off, futuristic concept. It’s here today, rapidly making its way into enterprises of all sizes. Unlike simpler, generative AI models that respond to a single prompt and then stop and wait for their next task, agentic AI systems can plan and execute multi‑step tasks, invoke external tools to do work, integrate seamlessly with other business systems, and most importantly, can act autonomously to reach a goal. As my colleague says, “Agentic AI doesn’t just tell you what to do — it actually does it.”

And from a security perspective, that shift changes everything.

AI Autonomy Creates Risk

Agentic AI introduces additional threats to the business that generative AI operational frameworks were not designed to address:

• Unauthorized operations: An agent with system access can perform actions directly — including harmful ones — if compromised or simply inadequately trained or constrained.
• Goal drift: Agents can creatively pursue perceived objectives in unintended ways and cause unintended, collateral damage.
• Adversarial manipulation: Malicious prompts or poisoned data can redirect agent to malicious behavior in the production environment.
• Integration exploitation: Because agents often interact directly with APIs, tools, and enterprise systems, they expand the organizational security attack surface.
• Memory poisoning: Persistent agent memory can become a vector for misinformation, bias, or manipulation.
• Accountability gaps: If an autonomous agent performs a harmful action, it may be unclear who is responsible and accountable for those acts.

Just like humans, the very autonomy that makes agentic AI so powerful also makes it vulnerable to attack and, without proper support and controls, potentially dangerous. The enterprise must treat AI as it treats any worker in the organization, and plan ahead for the potential vulnerabilities those workers may introduce.

Existing Security Frameworks Aren’t Enough

Standards like the NIST AI Risk Management Framework and ISO/IEC 42001 give broad guidance on managing AI risk. But they weren’t built for autonomous systems capable of initiating actions, chaining decisions, or using tools on their own.

Adopting agentic AI requires the enterprise to also adopt:

• New architectural safeguards that design security and integrity directly into agentic systems.
• New runtime monitoring approaches to catch and prevent errors and breaches proactively.
• New responsibility and accountability models that merge AI and human activities.
• New threat categories directly related to AI specific activities.
• New lifecycle controls to prevent the introduction of threats or vulnerabilities into change pipelines, which are much more dynamic in an AI environment.

The existing security frameworks at most organizations simply aren’t prepared to deploy agentic AI into the production environment, and the opportunity to have your business processes compromised is very real.

The Path Forward

While all this might sound daunting, there is no difference in deploying AI into your organization as there would be with any human or system based operational or decision support technology. There is a framework and set of steps to follow. At a high level. organizations that want to safely capture agentic AI’s benefits and beyond must:

• Understand the new threat landscape that agentic AI brings
• Architect and Design your autonomous AI systems with proper guardrails
• Shift from “model‑centric” to “agent‑centric” governance
• Build accountability, explainability, and oversight into every layer of the agentic system
• Treat agentic AI as a living system that evolves — and must be monitored and adjusted continuously

The agentic AI future is coming fast, and securing it properly could be the difference between a great success and a hasty, and costly retreat.

In the next article, we’ll explore the full threat landscape of agentic AI and break down the categories of risk executives must understand before deploying autonomous systems.

The post Agentic AI Is Coming to the Enterprise — Are You Ready? appeared first on Centrilogic.

Build once. Use many times.

Fabric Operating Model Series (Post 2): Why OneLake only becomes a multiplier when ownership, semantics, and trust become default.

I’m still riding the high of Arsenal reaching a cup final. And it’s a useful reminder for this topic: you don’t get there on hero moments alone. You get there because the system holds up week after week, even when the game gets messy. That’s basically the difference between building data like a project and building it like a product.

This is the OneLake post I teased in my last article, focused on what it actually takes to make reuse and trust scale.

Most organizations don’t have a data problem. They have a product problem. They build data like a project: one-off pipelines, one-off models, one-off dashboards. Success gets measured by delivery, not adoption. Then the next team rebuilds the same thing because it’s faster than figuring out what already exists.

Treating data like a product is the shift from “we delivered it” to “it’s used, trusted, governed, and improving.” And OneLake, done right, makes that shift easier because it nudges teams toward shared foundations and reuse instead of copy-and-customize.

What “data as a product” actually means

A data product is not a dataset with a fancy name. It’s a business capability with standards.

A useful definition is simple: A data product is a governed, reusable, trusted asset with clear ownership and measurable expectations.

That means every serious data product has:

• An owner: Not “the data team.” An accountable domain owner who can answer, “Is this right?” and “What changed?”
• A consumer: If nobody consumes it, it’s not a product. It’s inventory.
• A contract: What it contains, how it’s defined, how fresh it is, and what “quality” means.
• A lifecycle: Versioning, change management, deprecation. Businesses change. Products need to keep up.
• A support model: When something breaks, who fixes it, and how fast?

This is where many programs quietly fail. They ship assets, not products.

Why OneLake is strategic (and not just “storage”)

OneLake matters because it supports a different default behavior – Build once, use many times.

When the operating model is “copy data to make it usable,” you get:

• duplicated truth
• duplicated cost
• duplicated governance work
• duplicated failure modes

A OneLake mindset doesn’t magically eliminate duplication. But it creates the possibility of shared access patterns and consistent governance without rebuilding the foundation for every team and every use case. That matters because reuse is where the ROI lives.

The three disciplines that separate a “nice lake” from a real strategy

If you want OneLake to become an advantage, focus on these three disciplines. They’re not glamorous, but they’re decisive.

1) Ownership (who is accountable): Domain ownership with platform guardrails. This is how you scale without creating a central bottleneck.

2) Semantics (what things mean): This is the part most teams skip, and the part AI will punish the hardest.

If “net revenue” means five different things, the platform is not the issue. The meaning is. We’ve seen this play out in the wild: Finance defines net revenue after returns and discounts, Sales reports bookings, RevOps blends pipeline with recognized revenue, and someone else quietly excludes a region “for consistency.” All of them have a rationale. None of them are the same metric. And it usually gets discovered when the exec deck is already out.

This is the data equivalent of a casual back pass that gets intercepted. It feels harmless until it ends up in the net during an exec review. Semantics is what turns raw data into decision-grade data.

3) Trust (how you prove it’s reliable): Quality signals, lineage, certification, freshness expectations, access controls. Trust that’s designed into the system, not trust that depends on escalations and late-night triage.

A practical way to start (without boiling the ocean)

Pick one domain where the business already cares about outcomes (finance, sales, supply chain, customer ops). Then define one high-value data product.

Not ten. One.

Trying to launch ten data products at once is how you score an own goal. Everyone is busy, nobody is aligned, and the basics get missed. Make it boringly clear:

• Owner
• Consumers
• Definitions (semantic model)
• Refresh expectations
• Quality checks
• Access pattern

You’ll learn more from one real product than a hundred pages of “framework.” And yes, this is the part where someone will ask, “Do we really need all this?” You don’t need it for a demo. You need it for scale.

The operating model that makes OneLake pay off

If OneLake is on your roadmap, don’t treat it as a storage story. Treat it as a product operating model. The difference between “promising” and “scaled” usually comes down to a few shifts:

• Measure adoption, not delivery: Reuse rate, consumer satisfaction, freshness & quality SLAs, and time-to-trusted-data matter more than counts of pipelines or dashboards.
• Treat semantics as strategic: AI runs on meaning. If definitions drift, trust in automation breaks fast.
• Bake trust into defaults: Lineage, certification, access patterns, and lifecycle management should ship with the work, not show up after.

OneLake is not the answer to everything. It scales what you standardize. If ownership and semantics are fuzzy, you won’t scale value. You’ll scale inconsistency.

That’s the takeaway: OneLake isn’t the strategy. Data products are the strategy. Ownership, semantics, and trust built on shared foundations make reuse the default, and help teams spend more time making decisions than reconciling numbers.

The post OneLake Strategy: How to Treat Data Like a Product (Not a Project) appeared first on Centrilogic.

The post From Hype to Outcomes: The Agentic AI Advantage Webinar (Recording) appeared first on Centrilogic.

Multi-Agent AI Demo & Context:

The demo showcases a multi-agent, voice-based claims experience for an insurance company handling a car accident claim. One agent authenticates the caller and identifies intent;  a claims specialist agent gathers details; police and claims agents validate coverage and file a claim end-to-end. In this call-center scenario, identity verification and after-call summarization labeling can reduce handle time by 30-40% per call.

The post Business Automation at Scale with Agentic AI – Multi-Agent AI Demo (Recording) appeared first on Centrilogic.