Tag: transparency

  • Proposed amendment to BC 1.20.015(I) — Exhibit A, Item 5

    Mayor and Councilors,

    Thank you for the opportunity to comment on Exhibit A to Agenda Item 5 from the May 20 Business Meeting. I have one targeted suggestion for BC 1.20.015(I), City Manager Advisory Groups.

    As drafted, subsection (I) creates a category of informal or structured advisory groups, including technical advisory groups, focus groups, task forces, evaluation teams, and steering committees, that may or may not be subject to Oregon Public Meetings Law depending on the group’s role and authority.

    For surveillance-related work, that distinction matters. Vendor evaluation, pilot deployment, policy scoping, and early procurement recommendations often occur before a formal Council vote. If those discussions happen in informal structures that are not treated as public meetings, the public may not have meaningful visibility until the major choices have already been shaped.

    A narrow carve-out would close that gap without disturbing the rest of Chapter 1.20.

    Proposed addition to the end of BC 1.20.015(I):

    «Notwithstanding the foregoing, any group or committee created under this subsection whose scope includes the evaluation, selection, procurement, deployment, oversight, or policy governance of surveillance technology shall comply with the notice, access, minutes, and other open-meeting requirements of Oregon Public Meetings Law, regardless of whether the group or committee makes a recommendation to the City Council or another advisory body.»

    Recommended companion definition, added to BC 1.20.005 or incorporated by reference:

    «“Surveillance technology” means any electronic device, system, hardware, software, or hosted software solution used, designed, or primarily intended to collect, retain, analyze, process, or share audio, visual, biometric, location, or other data associated with identifiable individuals or groups. The term includes, without limitation, automated license plate readers, facial recognition systems, body-worn and fixed-location cameras with analytic capability, drones and aerial surveillance platforms, cell-site simulators, social media monitoring tools, predictive policing software, and data aggregation or fusion platforms. The term does not include standard office productivity software, routine IT security tools, or city-operated infrastructure cameras used solely for traffic signal operation.»

    The “notwithstanding” construction is intended to make this a narrow exception to the discretionary language earlier in subsection (I), without requiring broader changes to Chapter 1.20. The verb list is intentionally broad enough to cover the full procurement and policy lifecycle. The definition is also modeled on language used in comparable surveillance oversight ordinances adopted in cities such as Oakland, Seattle, and Cambridge.

    Respectfully,

    Jonathan

  • Questions Bend Residents Can Ask Council

    Questions Bend Residents Can Ask Council

    Part 10 of the Bend Surveillance Oversight series.

    You do not need to be a surveillance expert to ask reasonable questions about public technology.

    If a city uses tools that collect, store, search, analyze, or share public data, residents have a right to understand how those tools are governed.

    That applies to body cameras, fleet cameras, automated license plate readers, drones, traffic enforcement cameras, digital evidence systems, AI tools, real-time information platforms, and any other technology that affects public privacy, public records, or public accountability.

    The goal is not to attack City staff or police.

    The goal is simple:

    Public safety technology should answer to public rules.


    1. What systems exist?

    • What surveillance technologies does Bend Police currently use?
    • What systems are being considered for future use?
    • Which systems are active now?
    • Which systems are approved but not yet active?
    • Which systems are optional add-ons or future capabilities?
    • Which vendors are involved?
    • Are there third-party vendors, subcontractors, cloud providers, or software modules the public should know about?
    • Is there a plain-language public inventory residents can read?

    2. What data is collected?

    • Does the system collect video?
    • Does it collect audio?
    • Does it collect license plate data?
    • Does it collect location data?
    • Does it collect metadata?
    • Does it collect biometric data?
    • Does it analyze faces, vehicles, objects, movement, behavior, or patterns?
    • Is any data analyzed by AI or automated tools?
    • Are any features disabled but technically available?

    3. Where does the data go?

    • Where is the data stored?
    • Is it stored on City systems or vendor-controlled cloud systems?
    • Does the City own and control the data?
    • Can vendors access the data?
    • Can vendors process, export, or analyze the data?
    • Are cloud providers or subprocessors involved?
    • Can data be stored outside Oregon?
    • Can data be stored outside the United States?
    • What happens to the data when the contract ends?

    4. How long is the data kept?

    • What is the default retention period for each system?
    • Is non-evidence data automatically deleted?
    • Is non-hit ALPR data deleted quickly?
    • Who can extend retention?
    • What justification is required to extend retention?
    • Are retention changes logged?
    • Are retention settings audited?
    • Does the City publish retention rules publicly?

    5. Who can search the data?

    • Who has access to each system?
    • Are users limited by role?
    • Can every officer search the system?
    • Can supervisors search it?
    • Can dispatch search it?
    • Can prosecutors access it directly?
    • Can vendors access it?
    • Can outside agencies access it?
    • Are searches required to include a case number or incident number?
    • Are searches required to include a purpose?
    • Are all searches logged?
    • Are search logs audited?
    • What happens if someone searches improperly?

    6. Can outside agencies access it?

    • Can federal agencies access Bend surveillance data?
    • Can out-of-state agencies access it?
    • Can regional law enforcement systems access it?
    • Can fusion centers access it?
    • Can private companies access it?
    • Can vendors respond directly to outside requests?
    • Does the City require case-specific legal process before sharing?
    • Does the City require written authorization before sharing?
    • Does the City publish annual data-sharing statistics?
    • Can the City deny outside requests?
    • Can the City audit outside access?

    7. Can vendors activate new features?

    • Can vendors activate new AI features?
    • Can vendors activate analytics features?
    • Can vendors activate biometric tools?
    • Can vendors activate ALPR features?
    • Can vendors activate real-time monitoring?
    • Can vendors change retention settings?
    • Can vendors change data-sharing settings?
    • Does Council approval happen before new capabilities are enabled?
    • Does the public receive notice before major feature changes?
    • Are disabled features independently verified?

    8. What about facial recognition and biometrics?

    • Does Bend use facial recognition?
    • Does Bend plan to use facial recognition?
    • Do any current systems have facial recognition capability?
    • Are biometric features disabled?
    • Who verifies that they are disabled?
    • Would Council approval be required before biometric features are activated?
    • Would the public receive notice?
    • Would there be legal review and technical review first?

    A simple local rule would be:

    No facial recognition or biometric identification without explicit public approval.


    9. What about AI police reports?

    • Does Bend use AI-assisted police reports?
    • Does Bend plan to use AI-assisted police reports?
    • If AI is used, are original AI drafts preserved?
    • Are officer edits logged?
    • Does the final report disclose AI assistance?
    • Are prosecutors notified when AI was used?
    • Can defense attorneys obtain AI drafting records through normal discovery?
    • Can the vendor use Bend data to train AI models?
    • Has the system been independently audited?
    • Are serious incidents excluded or subject to extra safeguards?

    A simple local rule would be:

    No AI-generated police report without an audit trail.


    10. What oversight exists?

    • Has the City conducted an independent technical audit?
    • Does each system have a public use policy?
    • Does each system have a public retention policy?
    • Does each system have a public sharing policy?
    • Are complaints tracked?
    • Are violations reported publicly in aggregate?
    • Does Council review surveillance systems before renewal?
    • Does the City publish annual transparency reports?
    • Are total annual costs publicly reported?
    • Are future renewals and expansions clearly identified?

    11. What safeguards will Bend adopt?

    • Will Bend adopt a surveillance technology ordinance?
    • Will Bend require Council approval before acquisition or expansion?
    • Will Bend publish a public inventory of all surveillance technologies?
    • Will Bend require public use policies before deployment?
    • Will Bend set short retention limits?
    • Will Bend require logged searches with case numbers?
    • Will Bend restrict federal and third-party sharing?
    • Will Bend prohibit facial recognition without explicit public approval?
    • Will Bend require independent technical audits?
    • Will Bend require annual public transparency reports?
    • Will Bend prohibit vendors from activating new capabilities without City approval?
    • Will Bend require public review before contract renewal?

    A short version residents can send

    Residents who want to keep it simple can ask Council this:

    Before Bend expands police surveillance technology, will the City publish a plain-language inventory of all systems, identify what data each system collects, explain where the data is stored, disclose retention periods, require logged searches with case numbers, restrict federal and third-party sharing, prohibit facial recognition without explicit public approval, and require annual public transparency reports?

    These are not anti-police questions.

    They are public governance questions.

    If a technology is powerful enough to collect, search, store, analyze, or share public data, it is powerful enough to deserve public rules.

    Bend residents deserve clear answers before police surveillance systems expand.


    Further reading


    Series links

  • What Reasonable Safeguards Would Look Like in Bend

    What Reasonable Safeguards Would Look Like in Bend

    Part 9 of the Bend Surveillance Oversight series.

    This does not have to be a yes-or-no fight over police technology.

    Bend can support legitimate public safety tools while still requiring strong public oversight.

    The real question is not whether technology should ever be used.

    The real question is whether powerful systems are governed by clear public rules before they expand.

    Body cameras, fleet cameras, ALPRs, drones, traffic enforcement cameras, digital evidence systems, AI tools, and real-time information platforms all raise different questions.

    But they also share a common issue:

    They collect, store, search, analyze, or share public data.

    That means Bend should have a citywide surveillance technology policy.

    Not a vague promise.

    Not vendor assurances.

    Not scattered contract language.

    Not internal rules that residents cannot easily find.

    A clear public framework.


    1. Public inventory of surveillance technologies

    Bend should publish a plain-language inventory of all police surveillance technologies.

    That inventory should identify:

    • the technology name,
    • the vendor,
    • the department using it,
    • the purpose of the system,
    • what data it collects,
    • where the data is stored,
    • how long the data is retained,
    • who can access it,
    • whether outside agencies can access it,
    • whether vendors or subcontractors can access it, and
    • whether any AI, biometric, analytics, or automated decision features are enabled or available.

    Residents should not need to search scattered agendas, contracts, staff reports, and vendor documents to understand what systems exist.


    2. Council approval before acquisition or expansion

    Bend should require Council approval before any department acquires, renews, expands, or materially changes surveillance technology.

    That should include new tools, new vendors, major software modules, AI features, biometric capabilities, data-sharing expansions, and contract amendments that materially change what a system can do.

    Public approval should happen before deployment, not after the system is already operating.


    3. Public use policy before deployment

    Every surveillance technology should have a public use policy before it is deployed.

    That policy should explain:

    • the approved purpose,
    • allowed uses,
    • prohibited uses,
    • data collection rules,
    • retention rules,
    • access rules,
    • sharing rules,
    • audit procedures,
    • disciplinary consequences for misuse, and
    • how residents can find annual reports.

    The public should be able to read the rules before the technology is used.


    4. Short retention for non-evidence data

    Data retention should be limited.

    For non-evidence data, the default should be deletion after a short period unless the data is tied to a specific, documented case.

    For ALPR data, I would support a default rule like this:

    Non-hit ALPR data should automatically delete within 72 hours unless it is tied to a documented case, warrant, stolen vehicle, active investigation, or legally valid evidentiary need.

    Short retention allows legitimate use while reducing the risk that ordinary residents’ movements become long-term searchable records.


    5. Logged searches with case numbers

    If a system can be searched, every search should be logged.

    The log should identify:

    • who searched,
    • when they searched,
    • what they searched,
    • why they searched,
    • the case number or incident number,
    • whether the search produced a result, and
    • whether the result was shared.

    Search logs protect the public from misuse.

    They also protect officers who use the system properly.


    6. Limits on federal, out-of-state, private, and vendor access

    Local surveillance data should not become outside-agency data by default.

    Bend should limit access by federal agencies, out-of-state agencies, private companies, vendors, subcontractors, fusion centers, and other third parties.

    Access should require a documented purpose, legal authority, written authorization, and an auditable record.

    Broad sharing, informal access, and bulk access should be prohibited unless explicitly approved through a public process and consistent with law.


    7. No facial recognition or biometric identification without explicit approval

    Bend should prohibit facial recognition, biometric identification, biometric analytics, or similar identity-matching tools unless Council explicitly approves them after public notice, public debate, legal review, and technical assessment.

    If a system is technically capable of biometric analysis but the City says the feature is disabled, that should be independently verified.

    Disabled features should not become active through a quiet software update or vendor configuration change.


    8. AI report-writing rules

    If Bend ever uses AI to help draft police reports, the City should require strict auditability.

    The basic rule is simple:

    No AI-generated police report without an audit trail.

    That means preserving original AI drafts, officer edits, source transcripts, timestamps, final reports, supervisor edits, and disclosure that AI was used.

    Prosecutors and defense attorneys should be able to obtain relevant records through normal legal processes.


    9. Independent technical audits

    Bend should not rely only on vendor assurances.

    The City should require independent technical audits of surveillance systems.

    Audits should verify:

    • enabled features,
    • disabled features,
    • retention settings,
    • sharing settings,
    • access controls,
    • security controls,
    • vendor access,
    • subprocessor access, and
    • compliance with City policy.

    Trust is strongest when systems can be independently checked.


    10. Annual public transparency reports

    Bend should publish annual surveillance transparency reports.

    Those reports should include:

    • what systems were used,
    • what new systems were acquired,
    • how many searches occurred,
    • how many outside requests were received,
    • how many requests were approved or denied,
    • how many audits were performed,
    • whether misuse was found,
    • whether any new features were activated,
    • whether policies changed, and
    • what the total annual costs were.

    Transparency reports do not need to reveal sensitive case details.

    They should provide enough aggregate information for residents and elected officials to know whether the rules are working.


    11. Contract terms that match public policy

    Contracts should not undermine policy.

    If Bend adopts public rules, vendor contracts should match those rules.

    Contracts should prohibit vendors from changing settings, enabling features, expanding sharing, using data for product development, or using local public safety data for AI training unless the City explicitly approves it through the required public process.

    Good policy should be backed by enforceable contract language.


    12. Public review before renewal

    Surveillance technology should not renew automatically without public review.

    Before renewal, the City should publish a report explaining how the system was used, whether it met its stated purpose, what it cost, whether misuse occurred, whether audits were completed, and whether stronger safeguards are needed.

    Renewal should be a public decision, not an automatic default.


    The basic framework

    A reasonable Bend surveillance policy could be summarized like this:

    • Tell the public what systems exist.
    • Require approval before expansion.
    • Limit retention.
    • Log searches.
    • Restrict sharing.
    • Control vendor access.
    • Ban biometric use without explicit approval.
    • Audit AI tools.
    • Verify systems independently.
    • Report to the public every year.

    That is not anti-police.

    That is responsible governance.

    Powerful public safety tools should answer to public rules.


    Further reading


    Series links

  • Other Cities Are Already Asking Better Questions

    Other Cities Are Already Asking Better Questions

    Part 8 of the Bend Surveillance Oversight series.

    Bend does not need to invent police surveillance oversight from scratch.

    Other cities are already asking the same basic questions:

    • Who approves surveillance technology before it is used?
    • What data is collected?
    • How long is it kept?
    • Who can search it?
    • Can outside agencies access it?
    • Can vendors change settings or activate new features?
    • Does the public receive annual reports?
    • Can elected officials review the system before it expands?

    That is the important lesson.

    The issue is not whether every city has reached the same conclusion.

    They have not.

    The issue is that communities across the country are realizing that police technology should not expand faster than public oversight.


    Austin: surveillance technology should require public rules

    Austin offers one useful model.

    In February 2026, the Austin City Council passed a resolution called the Transparent and Responsible Use of Surveillance Technology Act, or TRUST Act.

    The resolution directed the City Manager to return with an ordinance regulating the adoption, acquisition, deployment, use, and review of surveillance technology by city departments.

    That matters because it shifts the question from one contract at a time to a broader public framework.

    Bend could take the same approach.

    The public question should not only be whether a single contract sounds reasonable.

    The broader question should be what rules apply before surveillance technology is acquired, expanded, renewed, or materially changed.


    Mountain View: vendor assurances were not enough

    Mountain View, California offers another useful lesson.

    In January 2026, the City publicly stated that it had discovered unauthorized queries and potential access to Mountain View ALPR data.

    The City said Police Department staff had met with Flock Safety leadership about “the security and control of our data,” and said it was “upset and disappointed with how our data was accessed.”

    That example matters because it shows why vendor assurances are not enough.

    The lesson for Bend is simple:

    Do not wait for a data-sharing problem before creating data-sharing rules.


    Pima County: cost and AI concerns can cross political lines

    Pima County, Arizona offers another example.

    Reporting in early 2026 described the Pima County Board of Supervisors rejecting a proposed $45 million contract expansion involving Axon technology and AI tools.

    Reported concerns included cost, AI expansion, and whether the investment made sense for the Sheriff’s Department.

    That example matters because surveillance oversight is not only a privacy issue.

    It is also a budget issue.

    Public safety dollars are limited.

    Every dollar spent on bundled technology, AI tools, cloud subscriptions, hardware refreshes, and add-on features is a dollar not spent somewhere else.

    That does not mean technology is never worth funding.

    It means elected officials should ask hard questions before long-term commitments become automatic.


    Ferndale: public pressure can lead to stronger oversight

    Ferndale, Michigan offers another useful example based on reporting about local ALPR oversight discussions.

    Reporting described residents raising concerns about license plate reader expansion and city officials discussing stronger policies.

    That is important because public oversight often improves when residents ask specific, grounded questions.

    Community engagement does not have to stop technology.

    It can improve the rules that govern technology.


    The pattern is bigger than one vendor

    This is not only about Axon.

    It is not only about Flock.

    It is not only about ALPRs.

    It is not only about body cameras.

    It is not only about AI.

    The larger issue is how cities govern powerful surveillance systems once cameras, cloud storage, software subscriptions, data-sharing, analytics, and vendor platforms become part of public safety operations.

    A city can support public safety and still insist on public oversight.

    Those goals are not opposites.


    What Bend can learn

    Bend can learn at least five things from other cities.

    1. Oversight should happen before deployment or expansion, not after controversy.
    2. Citywide rules are better than one-off contract debates.
    3. Data-sharing limits should be explicit and enforceable.
    4. Vendors should not be the only source of truth about how systems work.
    5. Annual public reporting builds trust without exposing sensitive case details.

    These examples do not prove that Bend has the same problems.

    They show why Bend should adopt safeguards before problems occur.


    Bend can ask better questions now

    Police technology can be useful.

    But useful tools still need rules.

    If other cities are asking stronger questions about surveillance technology, Bend can too.

    The question is not whether Bend should copy another city word for word.

    The question is whether Bend should create its own public framework before future expansions become harder to unwind.

    Better questions today can prevent harder problems tomorrow.


    Further reading


    Series links

  • AI Police Reports and the Audit Problem

    AI Police Reports and the Audit Problem

    Part 5 of the Bend Surveillance Oversight series.

    Police reports are not ordinary paperwork.

    They can shape criminal charges, court proceedings, plea negotiations, public records, insurance claims, disciplinary reviews, and a person’s ability to defend themselves.

    That is why AI-generated police reports deserve careful public oversight.

    The issue is not whether officers should use better tools.

    The issue is whether official police records remain accurate, reviewable, and auditable when artificial intelligence is involved.


    What AI police report tools do

    AI police report tools can use body-camera audio, transcripts, officer input, or other records to generate a draft narrative.

    That may sound helpful.

    Police officers spend a lot of time writing reports, and many departments are looking for tools that reduce paperwork.

    But a police report is not just a summary.

    It is an official law enforcement record.

    If AI helps write that record, the public should know:

    • what information the AI used,
    • what the AI produced,
    • what the officer changed,
    • whether the officer verified every factual statement,
    • whether the original AI draft was preserved,
    • whether errors can be reconstructed later, and
    • whether defense attorneys, prosecutors, judges, or oversight bodies can review the process.

    Without those safeguards, AI report-writing creates a serious audit problem.


    Why the original AI draft matters

    Imagine an AI tool creates a draft police report from body-camera audio.

    The officer reads it, edits it, and copies the final text into the official report system.

    Then the original AI draft disappears.

    Later, a defendant, attorney, judge, journalist, auditor, or oversight board wants to know whether a questionable sentence came from the officer, the transcript, or the AI system.

    If the original AI draft was not preserved, there may be no way to answer that question.

    That is the core problem.

    The concern is not only that AI can make mistakes.

    The concern is that AI mistakes may become embedded in official records without leaving a trace.


    What a basic audit trail should include

    A reasonable AI police report policy should require preservation of:

    • the original AI-generated draft,
    • the body-camera audio or transcript used to generate it,
    • the prompt or settings used,
    • timestamps,
    • the officer’s edits,
    • the final submitted report,
    • supervisor edits if any, and
    • a clear label showing that AI assisted in the drafting process.

    This should not be controversial.

    If AI saves time and improves accuracy, the audit trail should show that.

    If AI introduces errors, the audit trail should make those errors detectable.

    Either way, preserving the record protects the public, defendants, officers, prosecutors, and the City.


    Bend should set rules before using AI reports

    This post does not claim that Bend currently uses AI-assisted police report-writing.

    The point is that AI report-writing is already being marketed to law enforcement agencies, and cities should set rules before these tools become routine.

    Bend should not wait until after AI-generated police reports become common to decide how they should be governed.

    A strong local policy would say:

    1. No AI-generated police report may be submitted without officer review and certification.
    2. The original AI-generated draft must be preserved.
    3. All officer edits must be logged.
    4. The report must disclose that AI assisted in drafting.
    5. Prosecutors must be notified when AI was used.
    6. Defense attorneys must be able to obtain relevant AI drafting records through normal discovery.
    7. AI report tools may not be used for serious incidents unless additional safeguards are in place.
    8. The City must publish annual statistics on AI report use, error findings, officer adoption, and measured time savings.
    9. The vendor may not use Bend data to train AI models without explicit public approval.
    10. The City must independently audit the system before and after deployment.

    These rules would not ban AI.

    They would make AI accountable.


    No AI-generated police report without an audit trail

    Police reports are too important to become black boxes.

    If AI helps write an official record, the original AI output should not vanish.

    Bend residents should expect a simple rule:

    No AI-generated police report without an audit trail.


    Further reading


    Series links