A community organization does not need an AI strategy. It needs to know what its staff may use, with what information, and who checks the output before it reaches a client.

Published governance frameworks assume a compliance function, a data protection officer, procurement review, and an internal counsel to interpret them. An organization with eleven staff and a case manager doing intake in three languages has none of that, and is nonetheless making decisions every day about what goes into a commercial model.

We write governance at the level where those decisions actually get made: the intake form, the case note, the translated notice, the grant narrative, the eligibility screen.

What we do

• Organizational AI use policyWhat staff may use, for what purposes, with which data, and who is accountable for the result.
• Data handling and privacy standardsWhat must never enter a third-party model, how that rule is communicated, and how it is enforced in practice.
• Risk and bias assessmentWhere a given tool is likely to fail the specific population an organization serves, and what to do about it.
• Human review and oversight designWhich decisions require a person, at what point, and how the review is documented.
• Vendor and tool evaluationThe questions to ask before adopting, including where data is stored, retained, and used for training.
• Board and leadership briefingsPlain-language sessions for the people who carry legal and fiduciary responsibility for the decision.

Start with a policy

Most organizations begin with a use policy and a staff briefing. It takes a few weeks and leaves you with something you can show a funder, a board, and a client.

The real system of record is rarely the one that was paid for.

We routinely find organizations with a platform nobody can configure and three spreadsheets doing the actual work, an intake form that cannot be edited because the person who built it has left, reporting that no longer matches what the program does, and an automation whose failure mode is silence. One person usually holds the knowledge that makes any of it function.

None of this appears in a grant report. All of it determines whether the organization can answer a question about its own program, absorb a new contract, or keep operating in the week after something goes wrong.

What we build and repair

• Technology assessmentEstablishing what an organization actually needs, and what it already has, before anything is purchased, migrated, or replaced. Most of the expensive mistakes happen here.
• Data, case, and program systemsRecords that can be entered consistently, retrieved reliably, and reported on without a rebuild every time a funder asks a new question.
• Workflow designMapping how work actually moves through the organization, including the parts that live in someone's head, and building the system around that rather than the reverse.
• Integration and automationConnecting the tools an organization already pays for, so the same information is not being entered three times, with controls and a human step where the consequence matters.
• Staff training on the systems they runAdministrator training, written procedures, and enough practice that the people using a system daily can also change it, fix it, and explain it.
• Documentation and knowledge transferA named internal owner and documentation good enough that the system survives turnover, which is the most common way these things break.

What we assess and plan for

Emergency management has a mature discipline for this: continuity of operations, redundancy, single points of failure, degraded-mode procedures. It has almost never been applied to the technology community organizations run on.

• Continuity assessmentWhat stops working, and for how long, under a realistic range of failures. Not a document for the shelf, a list of things that would actually break.
• Single points of failureThe one person, the one tool, the one login, the one account nobody else can access. Usually the fastest and cheapest thing to fix.
• Degraded-mode proceduresHow to run intake, reach people, and keep records when the system is unavailable. Written to be usable by whoever is present, not by whoever built it.
• Data you can actually reachKnowing where client and program data lives, who can retrieve it, how quickly, and what happens if the vendor relationship ends.
• Verified communication channelsEstablishing and publishing where your real messages come from, so your community can tell your notice from an impersonation of it during an incident.

The measure is whether it still works a year after we go.

Consulting that produces dependency is one of the mechanisms that created this problem. Every engagement ends with documentation the organization holds, a trained internal owner, and procedures its staff can explain without calling us.

Training carries two obligations. One is to help staff use these systems without exposing the people they serve. The other is to equip an organization to explain to its own community how these systems work and when one has been used on them.

Most AI literacy curricula teach prompting. Prompting is the least consequential thing a community organization needs to know. What determines outcomes is what the system retains from the information it is given, which populations it is most likely to be wrong about, and whether anyone can establish after the fact that software contributed to a decision.

Sessions are built on the organization's own tools, caseload, and language access needs. We do not deliver a standard deck.

Fluent output and reliable output are indistinguishable to the reader

People express alarm about AI in the abstract and act on its specific outputs without hesitation. Both follow from the same absence: nobody has explained what happens between the question and the answer.

Fifty years of consumer software established a reasonable expectation. A spreadsheet does not invent a sum. A search engine returns pages that exist. Those systems fail visibly, by returning nothing or by returning an error. A language model fails by producing a complete, well-structured, plausible answer, which is the one failure mode nothing in ordinary computing experience anticipates.

The ordinary signal for calibrating trust is also absent. In conversation, uncertainty surfaces as hedging, qualification, a pause. The register does not shift between output that reproduces something accurate and output that generates a case citation, a filing deadline, or a dosage that does not exist. The reader is asked to distinguish reliability from fluency using only fluency.

The stakes scale with what a person can otherwise obtain. For someone who has never had access to a lawyer, an accountant, or a second medical opinion, a system that responds immediately, at no cost, and without condescension is not a convenience. It is the most substantive advice they have been able to get. Instructing that person to be skeptical accomplishes nothing. Demonstrating how the answer was constructed changes what they do with it.

Detection training teaches a skill that expires and produces false confidence

We do not teach people to identify fabricated images, audio, or video. The visual and acoustic artifacts that made detection possible in 2023 are largely gone, the remaining ones change with each model release, and a person who believes they can reliably spot a fake is measurably worse off than one who assumes they cannot.

The more consequential effect is on genuine evidence. When any recording might be synthetic, an authentic one can be dismissed without argument. That cost falls on people whose only available leverage has been documentation: photographs of housing conditions submitted to a code enforcement complaint, a recording of a wage discussion, damage images filed with an insurer, footage of an encounter with an official. Communities without institutional standing have relied on the evidentiary weight of a photograph. That weight is what is being eroded.

The alternative is provenance. The question that still has an answer is not whether an image is authentic but where it originated and whether a chain of custody exists between the source and the viewer. This shifts the burden from assessing content, which is no longer tractable, to establishing channels, which is.

For an organization, that is a set of concrete steps: designate and publish the channels your communications actually come from, state in advance the requests you will never make, and maintain a single point where anything can be verified. This is the architecture used against phone and payment fraud, and it holds because it requires no one to evaluate a message on its merits.

Training and education

• How a response is constructedThe output is a statistically likely continuation of the text supplied. Absent a connected source, no retrieval occurs, and no step exists at which the result is checked against anything. Every other failure on this list follows from that.
• Fabrication (hallucination, or confabulation)Case citations, statutory deadlines, eligibility requirements, and dosages that do not exist, produced in the same register as accurate material and frequently accompanied by a plausible source. Confabulation is the more precise term, since nothing is being perceived that is not there; plausible detail is being generated where none was available.
• Accommodation of the question (sycophancy)A premise supplied in the question tends to be carried into the answer. Phrasing that contains an assumption returns output confirming it. The term is sycophancy, and it describes a training artifact rather than an intent: agreeable responses score better in human preference ratings, and that tendency is reinforced along with everything else. It is the most consequential property for anyone reasoning about their own circumstances, because a fabricated citation can be checked and a confirmed assumption cannot.
• Where reliability degradesLocal ordinance, recent regulatory change, and the particulars of an individual case. These are the questions people bring most often.
• Bias and incidenceWhere disparate performance originates in training data and evaluation, why it concentrates on the populations community organizations serve, and how to test for it without technical staff.
• Synthetic media and channel integrityWhy detection fails, what provenance means operationally, and how to establish a verification channel a community can use.
• Data exposureClient identifiers, case detail, immigration status, and health information, with retention and training-use terms read against the actual products in use.
• Safeguards in operating procedureReview points, disclosure, documentation, and escalation, placed where the work already happens rather than added alongside it.
• Failure during emergenciesMisinformation in an active incident, automated resource allocation, impersonated official communication, and dependence on systems at the point of highest consequence.

Delivered to staff, leadership, boards, and community members. Sessions include live demonstration of these failure modes using the organization's own tools, which consistently accomplishes more than explanation.

Bring a session to your organization

Tell us who will be in the room, which tools are already in use, and how much time you have. We build the session against that.

An automated decision has usually already been made by the time anyone in the community hears about it, and there is rarely a way to ask how or to contest it.

Screening models decide who is offered an apartment. Eligibility and fraud-detection systems flag public benefits applications. Damage assessments and claim processing shape who receives disaster aid and how fast. Enforcement agencies build case leads from consolidated data. Schools and employers deploy monitoring software. Chatbots increasingly stand in for the caseworker who used to answer the phone.

Almost none of this is disclosed to the person affected. Appeal processes, where they exist, assume a human made the decision and can explain it. The result is a category of harm that is difficult to see, difficult to document, and disproportionately borne by people with the fewest resources to fight it.

There is a second harm underneath it. When people cannot tell which decisions are automated, they start treating all of them as suspect. Benefits go unclaimed. Real notices are ignored as scams. Services go unused by the households they were designed for. Opacity produces avoidance, and avoidance is rarely counted as a cost of deployment.

How we work on this

• Documenting what is actually happeningCommunity listening sessions and structured case documentation with frontline staff, building an evidence base from the people affected rather than from institutional self-reporting.
• Disclosure and appeal rightsAdvocating that people be told when an automated system contributed to a decision about them, and given a route to contest it that a person will actually read.
• Procurement standardsPublic agencies are among the largest buyers of these systems. Testing, impact assessment, and disclosure requirements written into procurement reach further than guidance issued after deployment.
• Automated decisions in disasterAid eligibility, damage assessment, claim processing, and emergency communication are being automated with the least scrutiny and the highest stakes for survivors.
• Comment, testimony, and coalition workRegulatory comment submissions, agency testimony, and joint work with coalitions already organizing on housing, benefits, immigration, and disaster recovery.
• Plain-language explainersMaterials that let community organizations make these arguments themselves, in the rooms where we are not present.

Data centers and the communities hosting them

Nothing about artificial intelligence stays abstract once a substation goes in down the road. Data center siting is where these systems stop being software and become land, water, electricity, noise, truck traffic, and a line on a utility bill.

The rules for this are being written now. Permitting pauses, rate structures, environmental review standards, and host-community benefit frameworks are all in active development, and the decisions made over the next year will set precedent for a decade. Each of those processes carries proceedings, comment periods, and local hearings.

Meanwhile the communities asked to weigh in are handed interconnection studies, load forecasts, water withdrawal filings, and tax abatement agreements. In most places that lands on a volunteer planning board with no technical staff, across the table from developers with full legal and engineering teams. It is the same gap we work on everywhere else, in its most concrete form.

• Plain-language briefingsWhat a proposed facility actually means for the grid, local water, ratepayer costs, noise, land use, and the tax base, written for residents and board members rather than for regulators.
• Reading the filingsHelping community organizations and local officials interpret and question technical submissions, and identify what has not been disclosed.
• Rulemaking and community benefitParticipation in the proceedings now setting standards, rate classes, and host-community benefit terms, so those terms are shaped by the places absorbing the impact.
• The resilience questionWhat large new loads mean for grid reliability during heat waves and storms, and who loses power first when the system is stressed.

We take no position for or against data center development as such. We work on whether the communities hosting these facilities can participate in the decision on equal technical footing.

Listening sessions

Policy conversations about AI and equity are held largely among institutions, and the evidence base is largely surveys of institutions. Meanwhile a tenant has been screened by a model nobody disclosed, a benefits application has been flagged for reasons no one will name, and a family has acted on a translation that was wrong in a way no one caught.

We run structured listening sessions with community members and frontline staff to document these encounters. Findings inform our advocacy, feed our training curriculum, and are published so other organizations can use them.

About GenBridge

GenBridge is a 501(c)(3) nonprofit working on community resilience at the point where it depends on technology.

Resilience is the capacity to take a hit and keep operating. For the organizations holding a community together, that now means three things at once. The systems they run on have to survive a storm, a vendor outage, and the departure of the one person who understood the database. The information people rely on has to be distinguishable from fabrication, during an emergency and on an ordinary day. And the automated decisions increasingly made about them have to be visible and contestable rather than silent and final.

Automated systems are now embedded in decisions across nearly every field community organizations work in: who is screened out and who advances, which requests are prioritized, how risk is scored, where resources are directed, and what information reaches a household. The organizations rooted in those communities are the ones people turn to when something goes wrong, and they hold the relationships and the local knowledge any response depends on. Almost none of them have technical staff, legal counsel, or a seat where the rules are set.

GenBridge works both ends of that gap. We write the policies, run the training, and plan for the failures inside these organizations, and we take what surfaces there into rulemaking, comment, and advocacy on the systems being used on the communities they serve. The two halves inform each other: a governance recommendation is only as good as the understanding of what an organization actually runs on, and a policy argument is only as good as the evidence behind it.

Our approach

• Resilience is the measureEvery engagement is judged by what an organization can still do when something fails, not by what it can do on a good day.
• Capacity, not dependencyEvery engagement ends with documentation the organization owns and a trained internal owner.
• Governance sized to the organizationFrameworks built for institutions with legal departments do not transfer down. We write for the conditions that exist.
• Evidence from the frontlineResearch begins with what community members and frontline staff actually do, not with what institutions report.
• Preparedness over reactionWhether the risk is a storm, a data exposure, or a model failure, the work is cheaper and better before the incident.
• Claims we can supportWe describe what we have done. We do not inflate credentials in security, research, or policy.

Who we are

GenBridge is directed by a volunteer team and draws on a network of practitioners engaged by project: technologists, emergency management professionals, trainers, community organizers and researchers who have built and maintained systems for mission-driven organizations in the United States and abroad.

Full biographies may be provided in grant applications, contract submissions, and on request to funders and partners.

Request support

GenBridge is taking on a small number of partner organizations. Formal nonprofit status is not required. Tenant associations, mutual aid networks, congregations, parent groups, and block associations are as welcome here as incorporated nonprofits.

Organizations come to us when staff are already using AI and nobody has written down the rules, when a funder or contract asks for an AI or data policy, when a system was inherited from someone who left, or when the reporting no longer matches what the program actually does.

They also come because the people they serve are asking questions no one on staff can answer: whether an application was screened by software, whether a notice is real, what happens to information typed into a chatbot. We build the sessions for that, run them alongside you, and leave you the materials to run them again.

Fund or contract this work

Every organization we support is one that could not have purchased this work. Philanthropic and public funding is what makes it free at the point of delivery.

• Program and general operating supportFunds AI governance, training, and technology capacity engagements with grassroots organizations.
• Research fundingSupports community listening sessions and published findings on AI in low-resource settings.
• Contracts and RFP responseTraining, technical assistance, facilitation, and policy work for agencies and larger institutions.
• Subcontracting and teamingWe partner with established primes on technology capacity and AI governance components.

What a technology company can contribute

The organizations we work with are running on donated licenses, discounted platforms, and free tiers, and they are adopting AI the same way. Companies building these systems are in a position to shape whether that adoption goes well, and most of what is useful here is not cash.

• Program fundingDirect support for AI literacy and responsible-adoption training with community organizations, delivered train-the-trainer so each engagement reaches beyond the staff in the room.
• Skills-based employee volunteeringEngineers, data scientists, security staff, and designers working alongside us on assessments, documentation, and curriculum review. This is frequently the most valuable contribution and the easiest one to authorize.
• Technical review of curriculumHaving researchers verify how we describe model behavior, failure modes, and data handling. It costs a company very little and materially raises the accuracy of what reaches thousands of people.
• In-kind technology for partner organizationsLicenses, seats, and credits passed through to the community organizations we support, rather than to us. They are the ones operating without a budget for tools.
• Documentation and disclosurePlain-language material on what a product retains, what it uses for training, and where human review is expected, written for an organization with no legal counsel to interpret terms of service.