{"resourceId":"portland-ai-rule-embedded-inhouse-review-2026","versions":[{"version":"external-01c3792934278c4d7fa79e0b012a71b1fbd88c3bb1e951c134bb252e242241d2","resource":{"id":"portland-ai-rule-embedded-inhouse-review-2026","title":"Portland extends AI review to embedded features and internally developed systems","organization":"City of Portland, Bureau of Technology Services","sector":"Municipal technology governance","geography":"Portland, Oregon, United States","publishedAt":"Exact page publication date unknown; rule effective March 6, 2026","publicationDate":null,"eventDate":"2026-03-06","sourceName":"Portland.gov","sourceLabel":"Official administrative rule; implementation effectiveness not evaluated","sourceUrl":"https://www.portland.gov/policies/technology-services/bts-404-artificial-intelligence-use-and-governance","evidenceClass":"standards-guidance","outcomeClass":"emerging","topics":["developers-agents","data-security","governance-procurement","accessibility-workforce","operating-model"],"finding":"The rule covers internal development and AI added to existing systems, beyond the initial purchase.","sledRelevance":"A new-to-archive U.S. municipal control design addressing purchasing blind spots. Its requirements apply to Portland; adoption elsewhere requires local tailoring.","evidence":"BTS reviews business cases and risk. Equivalent documentation is required for in-house AI, and bureaus must notify BTS when existing systems gain AI. Vendor model training with city data requires written authorization. Contracts require verification rights proportionate to risk. Public-facing use requires disclosure and language access. No compliance sample, error baseline or outcome evaluation is provided.","architectureImplications":"Interpretation: Map feature changes and data flows into release management, including developer-built agents. The rule does not select a hosting architecture.","governanceImplications":"Interpretation: Make review triggers executable in existing change and service-management processes.","securityPrivacyImplications":"Interpretation: Verify supplier data use through testable evidence and contract rights rather than relying solely on declarations.","caveats":"Policy existence does not prove enforcement. Supplemental public guidance was inspected; detailed employee usage guidance requires intranet login and was not accessed.","streamIds":["local-government"],"roles":{"sales":"Interpretation: Engage procurement, security, bureau IT and the service owner around the risk of unreviewed functionality entering existing software. Ask who notices supplier changes, who can disable a feature, and whether internal applications appear in the same inventory. A bounded discovery engagement can trace a small set of services from contract to production configuration. The value hypothesis is fewer unowned review gaps and more predictable approvals, not guaranteed compliance or savings. Use Portland as a concrete discussion example, not a national mandate. Confirm that a smaller locality can staff the proposed process, and avoid offering a broad governance transformation when one change workflow would address the demonstrated problem.","engineering":"Interpretation: Connect software inventory, supplier release notices and internal deployment records to a review queue. Prerequisites include named system owners, architecture diagrams and access to administrative configuration. Test whether a newly enabled summarizer or internally built agent is detected and held pending the correct decision. Examine data retention, model-training permissions, authentication and the ability to disable or roll back features. Validate an entire workflow rather than only completion of a questionnaire. No source evidence establishes that these controls are already operating effectively. For a proof of value, inject representative change scenarios and measure detection, routing and resolution against agreed requirements before adopting the process.","delivery":"Interpretation: Give the application owner responsibility for feature detection and the governance lead responsibility for resolving the review. Configure an intake path, document supplier dependencies, train support staff and rehearse escalation before wider rollout. Security, procurement and accessibility reviewers need allocated time and understandable evidence. Proposed acceptance criteria are that every selected test change reaches the correct reviewer, unauthorized data use is prevented, and a rejected feature can be disabled with service continuity preserved. These are proposed tests, not observed Portland results. Track overdue cases and user workarounds after launch. The main risks are hidden defaults, excessive review queues and policies that staff cannot implement with available permissions."},"retrievedAt":"2026-09-11T03:02:04Z","enrichedAt":"2026-09-11T03:04:59Z","enrichmentBasis":"retrieved source","accessibilityWorkforceImplications":"Interpretation: Test language access and staff review usability before release.","procurementImplications":"Interpretation: Include supplier feature-change notice and evidence access in a bounded contract review.","operatingModelImplications":"Interpretation: Assign an owner to detect new AI functionality after purchase and route it for review.","updateExplanation":"New to the full 182-resource archive checked across offsets 0 and 100. No substantive source update or post-last-run event is claimed.","sourceVerification":{"openedUrl":"https://www.portland.gov/policies/technology-services/bts-404-artificial-intelligence-use-and-governance","referenceExcerpt":"For AI systems developed by a bureau or project team, equivalent disclosures and documentation must be provided.","promptVersion":"sled-research-v3.1","model":null,"basis":"agent-reported inspection"}}}]}