From AI pilots to public decisions: what it really takes to close the intelligence gap
Across the public sector, the conversation about AI has shifted. The question is no longer whether AI can generate insight—most leaders have already seen impressive pilots. The harder question is whether those insights survive the realities of government: public scrutiny, auditability, cross‑department delivery, and the need to explain decisions in plain language. That challenge was recently articulated by Sadaf Mozaffarian, writing in Smart Cities World, in the context of city‑scale AI deployments. Governments don’t need more experiments. They need decision‑ready intelligence—intelligence that can be acted on safely, governed consistently, and defended when outcomes are questioned. What’s emerging now is a more operational lens on AI adoption, one that exposes two issues many pilots quietly avoid. Decision latency is the real enemy In government, decision latency is not about slow analytics, it’s the time lost between having a signal and being able to act on it with confidence. Much of the focus in AI discussions is on accuracy, bias, or model performance. But in cities, the more damaging problem is often this latency. When data is fragmented across departments, policies live in PDFs, and institutional knowledge walks out the door at 5pm, leaders may have insight but still can’t decide fast enough. AI pilots often demonstrate answers in isolation, but they don’t reduce the friction between insight, approval, and execution. Decision‑ready intelligence directly attacks this problem. It brings together: Operational data already trusted by the organization Policy and regulatory context that constrains decisions Human checkpoints that reflect how accountability actually works The result isn’t faster answers—it’s faster decisions that stick, because they align with how governments are structured to operate. Institutional memory is infrastructure Cities invest heavily in physical infrastructure—roads, pipes, facilities—but far less deliberately in institutional memory. Yet planning rationales, inspection notes, precedent cases, and prior decisions are often what make or break today’s choices. Consider a routine enforcement or permitting decision that looks reasonable on current data, but quietly contradicts a prior settlement, a regulator’s interpretation, or a lesson learned during a past inquiry. AI systems that don’t account for this history don’t just miss context, they create risk. Decision‑ready intelligence treats institutional memory as a first‑class asset. It ensures that when AI supports a decision, it does so with: Access to relevant historical records and prior outcomes Clear lineage back to source documents and policies Logging that preserves not just what was decided, but why This is what allows governments to move faster without relearning the same lessons under audit pressure. Why this matters now Public sector AI initiatives rarely fail because of a lack of ambition. They stall because trust questions—governance, records, explainability—arrive too late. By the time leaders ask, “Can we stand behind this decision?” the system was never designed to answer. Decision‑ready intelligence flips that sequence. Governance is not bolted on after the pilot; it’s built into the operating model from the start. That’s what allows agencies to scale from a single use case to repeatable patterns across departments. A practical starting point The cities making progress aren’t trying to transform everything at once. They start small but visible: Identify one cross‑department “moment of truth” Define what must be logged, retained, and explainable Connect just enough data, policy, and work context to support that decision From there, they reuse the same patterns—governed data products, policy knowledge bases, and human‑in‑the‑loop workflows—to scale responsibly. AI in government will ultimately be judged the same way every public investment is judged: by outcomes, fairness, and public confidence. Closing the intelligence gap isn’t about smarter models. It’s about designing decision systems that reflect how governments actually work—and are held accountable. Learn more by reading Sadaf's full article: Closing the intelligence gap: how cities turn AI experiments into operational impactAzure Government or Azure Commercial for CJIS 6.0: Choosing Your Compliance Path
Since 2014, United States criminal justice agencies have trusted Microsoft Azure Government to manage Criminal Justice Information (CJI). Built exclusively for regulated government data, it provides datacenters with physical, network, and logical isolation and is operated by CJIS-screened U.S. persons—the "gold standard" for compliance. However, we understand that flexibility is critical for modern agencies. As first announced with the release of CJIS Security Policy (CJISSECPOL) v5.9.1, agencies have the option to utilize Azure Commercial for CJIS workloads by leveraging advanced technical controls in place of traditional personnel screening. With the release of CJIS Security Policy 6.0, this hybrid landscape has evolved. The new policy moves beyond simple access control toward a "Zero Trust" framework which minimizes implicit trust, verifies all requests, and requires continuous monitoring. What’s New in CJIS 6.0? The 6.0 update (released late 2024) is a modernization overhaul. Key changes include: Phishing-Resistant MFA: Strict requirements for FIDO2 or certificate-based authentication for all privileged access. Continuous Monitoring: A shift from point-in-time audits to real-time threat detection and automated logging. Supply Chain Risk Management: Enhanced vetting of third-party software and vendors. The Choice: Azure Government or Azure Commercial: Criminal Justice Agencies can still choose between our two distinct offerings, but the "How" of compliance differs: Azure Government: The path of personnel screening. Microsoft executes CJIS Management Agreements with state CJIS Systems Agencies that include their screening of Microsoft personnel. This offers the broadest feature set with the simplest compliance burden. Azure Commercial: The path of technical controls. Because Azure Commercial support staff are not CJIS-screened, compliance relies on an agency implementing Customer Managed Keys (CMK) encryption. This way, Microsoft cannot access unencrypted criminal justice information, effectively removing Microsoft staff from the scope of trust. Our Commitment Whether you choose the physically secure location of Azure Government or the global scale of Azure Commercial, Microsoft provides the tools—Entra ID, Azure Key Vault, and Microsoft Sentinel—to meet the rigorous demands of CJIS 6.0. Step-by-Step Walkthrough for CJIS 6.0 in Azure Commercial Managing CJI in Azure Commercial requires you to bridge the gap between "standard commercial security" and "CJIS compliance" using your own configurations. Because Microsoft Commercial staff are not CJIS-screened, you must ensure they can never see unencrypted data. Phase 1: Foundation & Residency Step 1: Restrict Data Residency CJIS 6.0 mandates that CJI must not leave the United States. Action: Deploy all Azure resources (compute, storage, disks, networking, monitoring, logging, backups, etc.) exclusively in US regions (e.g., East US, West US, Central US). Policy: Use Azure Policy to deny the creation of resources in non-US regions to prevent accidental drift. o Documentation: Tutorial: Manage tag governance with Azure Policy (See the concept of "Allowed Locations" built-in policy). o Documentation: Azure Policy built-in definitions and assignment (Allowed locations) o Documentation: Details of the "Allowed locations" policy definition. Phase 2: The "Technical Control" (Encryption) This is the most critical step for Azure Commercial. Step 2: Implement Customer Managed Keys (CMK) To meet CJIS requirements in Azure Commercial, which is operated by Microsoft personnel who aren’t CJIS-screened, you must use encryption where you hold the keys, and Microsoft has no access. Action: Provision Azure Key Vault (Premium) or Managed HSM for FIPS 140-2 Level 2/3 compliance. o Documentation: About Azure Key Vault Premium and HSMs. o Documentation: Secure your Azure Managed HSM deployment. Action: Generate your encryption keys within your HSM or import them from on-premises. o Documentation: How to generate and transfer HSM-protected keys (BYOK). Action: Configure Disk Encryption Sets and Storage Account Encryption to use these keys. Do not use the default "Microsoft Managed Key" setting. o Documentation: Server-side encryption of Azure Disk Storage (CMK). o Documentation: Configure customer-managed keys for Azure Storage. o Documentation: Services that support customer-managed keys (CMKs) Step 3: Client-Side Encryption (For SaaS/PaaS) For data processing, encryption should happen before data reaches Azure. Action: Ensure applications encrypt CJI at the application layer before writing to databases (SQL Azure, Cosmos DB). This ensures that even a database admin with platform access sees only ciphertext. Step 3b (optional): Protecting CJI While In Use (Confidential Compute) CJIS Security Policy 6.0 requires that Criminal Justice Information be protected while at rest, in transit, and in use. In Azure Commercial, once CJI is decrypted for processing by an application, traditional encryption controls (including CMK) no longer protect the data from platform-level access risks such as memory inspection, diagnostics, or hypervisor operations. To address this risk, agencies may implement Azure Confidential Computing, which uses hardware-backed Trusted Execution Environments (TEEs) to cryptographically isolate data in memory and prevent access by cloud provider personnel—even at the infrastructure layer. o Documentation: Always Encrypted for Azure SQL Database. o Documentation: Client-side encryption for Azure Cosmos DB. o Documentation: Confidential Computing o Documentation: Confidential Compute Offerings Phase 3: Identity & Access (CJIS 6.0 Focus) Step 4: Phishing-Resistant MFA CJIS 6.0 raises the bar for Multi-Factor Authentication (MFA). SMS and simple push notifications may no longer suffice for privileged roles. Action: Deploy Microsoft Entra ID (formerly Azure AD). o Documentation: What is Microsoft Entra ID?. Action: Enforce FIDO2 security keys (like YubiKeys) or Certificate-Based Authentication (CBA) for all users accessing CJI. o Documentation: Enable passkeys (FIDO2) for your organization. o Documentation: How to configure Certificate-Based Authentication in Entra ID. Phase 4: Continuous Monitoring Step 5: Unified Audit Logging You must retain audit logs for at least one year (or longer depending on state rules) and review them weekly. Action: Enable Diagnostic Settings on all CJIS resources to stream logs to an Azure Log Analytics Workspace. o Documentation: Create diagnostic settings in Azure Monitor. Action: Deploy Microsoft Sentinel on top of Log Analytics. o Documentation: Quickstart: Onboard Microsoft Sentinel. Action: Configure Sentinel analytic rules to detect anomalies (e.g., "Mass download of CJI," "Access from foreign IP"). o Documentation: Detect threats out-of-the-box with Sentinel analytics rules. Phase 5: Endpoint & Mobile Step 6: Mobile Device Management (MDM) If CJI is accessed on mobile devices (MDTs, tablets), CJIS 6.0 requires remote wipe and encryption capability. Action: Enroll devices in Microsoft Intune. o Documentation: Enroll Windows devices in Intune. o Documentation: Enroll iOS/iPadOS devices in Intune. Action: Create a Compliance Policy requiring BitLocker/FileVault encryption and complex PINs. o Documentation: Create a compliance policy in Microsoft Intune. o Documentation: Manage BitLocker policy for Windows devices with Intune. Action: Configure "App Protection Policies" to ensure CJI cannot be copied/pasted into unmanaged apps (like personal email). o Documentation: App protection policies overview. Phase 6: Personnel & Documentation Step 7: Update your SEIP/SSP Since you are using Azure Commercial, your System Security Plan (SSP) must explicitly state that you are using encryption as the compensating control for the lack of vendor personnel screening. Action: Document the CMK architecture in your CJIS audit packet. Action: Ensure your agency's "CJI Administrators" (who manage the Azure keys) have met the policy’s personnel screening requirements o Documentation: Microsoft CJIS Audit Scope & Personnel Screening (Reference).
Identity Verification Rejected in Partner Center – What Are the Next Steps?
Hello, our Microsoft Partner Center identity verification was rejected with the following message: 'Based on the information you have provided, your organization does not currently meet the requirements to pass verification. There are no appeals available, and the application has been closed.' We understand that this application is closed and that no appeal is available for this verification attempt. In addition, we are currently unable to create a support ticket in Partner Center for this verification issue, as the option to submit a ticket is not available to us. Could you please clarify: - What are the recommended next steps after receiving this message? - Is reapplying the correct action in this situation, and if so, what is the proper way to proceed? - Is there a required or recommended waiting period before reapplying? Thank you for your guidance.
CSP Account Verified & Authorized yet Indirect Reseller Status: SUSPENDED
Hello Partner Community Please assist any way you can... JillArmourMicrosoft is this in your wheelhouse? We are an CSP partner that is struggling to have our indirect reseller account suspension lifted even though our partner account is now fully verified and authorised. Our account was originally suspended due to a business registration vs shop location mismatch that was not resolved within a 30 day termination notification time limit. We corrected the address problem AFTER the account was suspended and although our account is now verified and authorised, the Indirect Reseller account suspension has not been automatically lifted and we are unable to contact a human representative to have it manually moved back to the Active state. We have submitted several Partner Support tickets but they do not provide actual support at all and automated responses from these tickets return a disclaimer stating the following with no further correspondence and the ticket automatically closed. Hello, Thank you for contacting Microsoft Partner support about the notice of suspension and termination proceedings. In the Microsoft AI Cloud Partner Program Agreement, both Microsoft and our partners reserve the right to walk away from the partner relationship by providing 30 days' notice to the other. Neither party is required to offer an explanation for the decision to terminate the partner agreement. As Microsoft is exercising its rights under this section 4.b of the Microsoft AI Cloud Program Agreement, we are unable to share an explanation or further details. Kind Regards, *Random Name* (He/Him) Support Engineer Partner Support Delivery - Program Customer Support My Working Hours: M-F 11:30 AM to 08:30 PM AEDT This lack of support is excruciatingly frustrating and terribly aggravating given that we are now subject to an indefinite period of considerable income loss with no recourse. Note that along with the suspension, emails have been sent to our customers notifying them that we are no longer qualified to act as their licensing provider which has been distressing for both our sales team and the customers. Our distributor is doing the best they can to help but they are unable to provide any real assistance and from what I hear, are unable to get any sensible advice from their Microsoft reps. Upon speaking with several other indirect resellers and distributors alike, it is my understanding that many partners are suffering the same or similar denial of service and I question whether this practice is even legal under Australian law regardless of any contractual fine print and disclaimers after the fact. This denial of support is a huge failure of Microsoft's policy makers and extremely poor business practice in general. If Microsoft wish to declare utter contempt for the small businesses that have supported them for several decades then those businesses might consider alternative platforms for their customers going forward. To conclude, I welcome any support or feedback from the community to help resolve this particular problem and help others with the same issue. Kind Regards, One very Frustrated Reseller.A CISO's Guide to Securing AI - Securing AI for Federal, DIB, and DoW Entities
Artificial Intelligence (AI) is rapidly reshaping federal missions, defense operations, and critical infrastructure. From intelligence analysis to logistics and cyber defense, AI’s transformative power is undeniable. Yet, with great power comes great responsibility and risk.
Unable to Register - "Legal Entity Already Exists" Error - Cannot Access Support
Hello, I'm trying to register for the Microsoft Partner Network to obtain an MPN ID for Azure app publisher verification, but I'm stuck in a catch-22 situation. The Problem: When registering through Partner Center, I receive this error: "A legal entity matching the request payload already exists when creating the legal entity" The Catch-22: I cannot create a support ticket because: - Partner Center help form requires selecting a workspace - I cannot create/access a workspace without completing registration - I cannot complete registration due to the duplicate entity error What I've Tried: - Searching for existing accounts within my organization - no one knows of any - Attempting to create a support ticket - blocked by the workspace requirement - Looking for alternative support channels - all redirect back to Partner Center What I Need: Either help locating an existing account for my company, obtaining the existing MPN ID, or resolving the duplicate registration issue. Has anyone successfully resolved this? Is there a direct contact at Microsoft Partner Support who can help? Any assistance would be greatly appreciated! Thank you.Legal-entities and sub-units in Microsoft Partner Center terms
Hi, I represent several partners with Microsoft, and we are fast growing. In our enterprise, we do as several others, we move around locations, merge them, and restructure to improve efficiency and quality. Recently Microsoft also notified us to update and improve several of our MPN/CSP identifiers with updated information, which resulted in this post about missing features and hidden Microsoft data not available in Partner Center. Starting out as a partner, you add your company in Partner Center, creating your PGA and first PLA account. Your PGA now refers to your legal entity, and your PLA is now a sub-unit under your PGA. So far so good (for a CSP business, you have your PGA be the MPN id and your PLA the CSP id). As time goes by, your business grows and you start buying other MS partner companies. In comes account merge in partner center to the rescue. This will merge your MPN (not CSP, I know, atleast not in terms of your GDAP or customer relationships, but everything else), so that all your competencies, reports and information is updated accordingly. The company you have bought and merged now still has their CSP business, but reporting under your PGA. Both their original PGA and PLA accounts are now PLA under you PGA. So far this seems to be good, but now you are missing out on some data hidden internally in Microsoft, that is nowhere to be seen, and impossible to update: this original merged PGA still refers to the original legal-entity, and the PLA is still NOT connected to your PGA, but the original PGA, which is now a PLA under your PGA. So, something like, Your PGA --> The merged PGA (which is now a PLA) --> The merged PLA. Confused yet? Now, this merged company should at some point in time become something else, maybe a department or separate location of your company. Or maybe you even move that as a department or location below some other company you have in your enterprise portfolio. Now comes the headache of updating your CSP - PLA identifiers with correct legal information. There is currently nowhere you can read what PLA id-s are considered as legal entities, and nowhere your PLA says which legal entity they are connected to. Even filing this with MS partner support is a no-go, this information is hidden so far behind support/MCAIPP/CSP/direct/indirect/vetting/engineering/developers and god knows what, that it is currently not possible to update any of it. Not even getting to read the structure of the identifiers is possible. I hope Microsoft can understand this is a big compliance issue over time. How many tax forms or payout accounts do you need? How many are using the same legal info for the same tax forms? Regardless of being a direct or indirect partner, who should really receive the bill? Who ends up as the owner of the different agreements? (I know this usually works out one way or another, but how many hours could have been saved on partner support if this was not a headache?) We need to be able to see where each identifier is connected in terms of sub-units and legal-entities. Whether by self-service or MS partner support, we need to be able to provide updates on this structure. We need to be able to change any PLA between being a legal entity or a sub-unit, and telling which legal-entity owns the sub-unit or parent legal-entity. Different partners have different setups, we have an enterprise setup where one company fully owns all the others and plan to fully merge them within a single legal entity, but still owned by the enterprise. Others have separate companies working together sharing Microsoft competencies and benefits under one umbrella. Having a way to let Microsoft know about structural changes and having this information visible and correct in partner center is crucial when working as a partner over time. Bonus tip: Most countries, even Norway has officially available records on all companies registered, on official website or by official APIs - by looking up any company registration id, you can have the 100% accurate information for all legal entities, and all sub-units, we even give you the company registration id inside partner center for your benefit.
Unable to update the primary contact email address during verification process
Registered my corporation on Microsoft Partner Center (MPC) about 2 weeks ago as the owner. Uploaded the incorporation document at that time. Then, it asked to upload the domain receipt to demonstrate the corporation owns the domain. Did that immediately. Now, the vetting status is still "Rejected". Also, when I check the "Legal Info" panel, my role is just "Developer" now, and there is no more "Owner" role for my account. Maybe because of this, I cannot see notification or expand "Contact info" for my corporation on MPC. I opened a support ticket and got an email saying the primary contact should not be general email like "email address removed for privacy reasons" and need to update it. But with the "Developer" role, I cannot even expand "Contact info" panel and won't be able to update it by myself now. This experience made me very frustrated with MPC. So I replied the support email, and who knows if they will actually reply or care.
Access restricted
I was banned from the system without any justification. I spent six months struggling to get approval without ever using the service once. Now I face another six months trying to get my ban lifted, and they're telling me that if I pay $16,500 annually for support services, they'll help me. This system is absolutely ridiculous. When I was banned, I received no notification, no message, no email, nothing. I only got a response after submitting four support tickets. Now I suppose I'll need to submit another 50 tickets just to try to get my ban reversed. Microsoft is truly a terrible company
