AI for
Nonprofits

What information will AI systems access, store, or generate. Who governs it?

• Inventory what client, donor, and staff data currently exists and where it livesSpreadsheets, CRMs, intake forms, email: all of it.
• Determine what data should never enter an AI toolHealth records, immigration status, financial details, anything subject to HIPAA or other regulations.
• Review the data privacy terms of any tool before signing upWhere is your data stored? Is it used to train the model? Can you delete it?
• Write or update your organization's AI data use policyStaff need clear rules about what they can and can't put into AI tools.
• Establish a repeatable process for preparing clean versions of documents before AI useScrub or redact sensitive fields before input (client names, case numbers, identifying details) rather than feeding raw files. This will happen regularly. The process needs to be documented and consistently applied, not handled ad hoc each time.

Physical security considerations are covered in Section C: screen visibility, shared workstations, and how to handle printed outputs.

Who benefits from this tool. Who might be harmed by it?

• Assess whether the tool could introduce or amplify biasAI trained on biased data produces biased outputs. Ask vendors directly about this.
• Consider how AI use might affect trust with your communitySome populations have legitimate reasons to distrust automated systems.
• Establish a clear human review process for AI-generated contentEspecially anything that affects individual clients or goes out publicly.
• Disclose AI use to your community where appropriateTransparency isn't weakness: it's accountability.

Does your team have what they need to use AI well. Can they push back when it's wrong?

• Identify who will lead AI adoption internallyThis person doesn't need to be a tech expert: they need to be trusted and curious.
• Plan real training time, not just a handoutBudget at least 2 to 4 hours of hands-on time per staff member at launch.
• Set clear expectations about human oversightAI writes the draft. A person reads it, edits it, and takes responsibility for it.
• Create a way for staff to flag problemsIf the AI is producing something wrong or harmful, staff need a clear path to report it.

How does AI fit into the work you already do. Where does it actually help?

• Map the tasks where AI will save the most timeWriting, summarizing, answering repetitive questions, formatting data.
• Identify tasks AI should not touchDirect client support, crisis response, any decision with serious consequences.
• Document your workflows before and after AI integrationThis helps you train new staff and catch drift over time.
• Build quality checks into the workflow, not on top of itReview before publish, not as an afterthought.

What does this actually cost. How do you make the case to funders?

• Calculate total cost of ownership, not just subscription feesStaff time for training, setup, ongoing review, and eventual tool switching.
• Estimate the time savings in hours per weekThis becomes your ROI story for board and funders.
• Look for nonprofit discounts and grant fundingMany AI providers offer discounted or free tiers for nonprofits. Some foundations now fund technology adoption.
• Plan for the tool to changeAI pricing and features shift constantly. Don't build a budget that assumes nothing changes.

Who is responsible when something goes wrong?

• Assign clear ownership over your AI policySomeone on staff: or the board: needs to be accountable for this.
• Set a regular review scheduleAt minimum, review your AI use quarterly in the first year.
• Define what would cause you to stop using a toolKnow your line before you need it.
• Keep the board informedAI adoption is a governance matter, not just a staff decision.

Every organization adopting AI needs someone who can do these things. Not an expert: someone competent and accountable.

• Prompt writing: knowing how to give an AI tool clear, specific instructionsThis is not a technical skill. It's a communication skill. Someone who writes well and thinks clearly can learn the basics in a few hours. The difference between a vague prompt and a specific one is usually the difference between a useless output and a useful one.
• Output evaluation: reading AI content critically and catching errorsAI sounds confident even when it's wrong. The person reviewing outputs needs to know your organization's programs, data, and voice well enough to spot when something is off. This is usually an existing staff member, not a hire.
• Basic data hygiene: knowing what should and shouldn't go into an AI toolThis is policy enforcement as much as skill. Someone needs to understand the data privacy policy well enough to apply it in practice and answer staff questions about edge cases.
• Vendor evaluation: reading a data privacy policy and asking the right questionsCovered in the vendor questions section of this guide. Not a technical skill: it requires knowing what to look for and being willing to push for clear answers.

These matter more once you're past a basic pilot and starting to integrate AI into core workflows.

• Understanding of how AI models work at a basic levelNot programming: just a working mental model of what these systems can and can't do, why they hallucinate, and why bias enters. Enough to explain it to a skeptical board member or a worried community partner.
• Workflow documentationWriting down how AI fits into existing processes so new staff can be trained and so you can catch drift over time. Usually a natural fit for someone already doing operations or communications work.
• Data literacy: reading a spreadsheet, interpreting a chart, asking good questions about dataIf you're using AI for donor analysis or program reporting, someone needs to be able to evaluate whether the outputs make sense. This isn't about building models: it's about not accepting outputs uncritically.
• Change managementGetting skeptical staff on board, handling the fear and frustration that comes with any new system, and keeping morale intact through the transition. Often the ED or a trusted program manager rather than a technical person.

What they need to know, and when.

• Brief the board before launch, not afterFrame it as a governance decision: which tools, which use cases, what oversight is in place, what's off-limits. Give them a chance to ask questions before it's operational.
• Report on it at least quarterly in the first yearWhat's working, what isn't, any problems that surfaced. Boards that feel informed are far more likely to support the work.
• Be honest about what you don't know yet"We're piloting this and will have more data in 90 days" is a better answer than overpromising outcomes you can't yet demonstrate.

An evolving conversation, and one worth starting proactively.

• Know your funder's AI policy before you submitA small number of funders have explicit policies about AI use in grant applications. Most haven't addressed it yet. If you're unsure, ask your program officer directly: it builds trust rather than undermining it.
• Disclose AI involvement in proposals when it's significantIf AI drafted substantial portions of a proposal, say so briefly. Something like: "Drafts were developed with AI assistance and reviewed and edited by staff." This is accurate, professional, and increasingly expected.
• Lead with what stayed humanThe program design, the community relationships, the theory of change: that's your staff's work. AI handled the formatting and language efficiency. Make that distinction clear.
• Use AI efficiency as a capacity storyIf AI allows your two-person development team to apply to three times as many grants, that's a legitimate organizational strength to share with funders who care about sustainability.

The people you serve have the most at stake. Treat that accordingly.

• Be transparent about where AI is involved in communicationsIf your newsletter or donor emails are AI-assisted, that doesn't need to be front-page news: but it shouldn't be hidden either. A brief note in your communications policy or website is enough for most organizations.
• Never use AI in direct client-facing interactions without disclosureIf a chatbot or AI tool is responding to community members on your behalf, they need to know they're not talking to a person. This is a basic trust and consent issue.
• Listen for community skepticism and take it seriouslySome communities: particularly those that have experienced algorithmic discrimination or surveillance: will have strong feelings about AI. Those concerns are legitimate. Address them directly rather than dismissing them.

• Chatbots for intake and initial screeningAutomated tools that ask initial eligibility questions, collect contact information, or triage service requests before connecting clients to staff. These reduce intake burden for small teams but introduce risks around accuracy, accessibility, and what happens when the chatbot is wrong.
• Translation tools for multilingual client communicationsAI translation has improved significantly and can help organizations reach non-English-speaking clients more quickly and consistently than before. The risk is over-reliance on machine translation for sensitive topics. Legal status, health information, safety planning. Nuance and accuracy are non-negotiable in those contexts.
• Automated scheduling and remindersLower-stakes and generally appropriate for most populations. The main considerations are accessibility (not all clients have smartphones or reliable internet) and whether the communication style fits your population.
• AI-assisted case documentationStaff using AI to summarize client notes or generate documentation templates. This is internal use even though it involves client information: but it carries the same data privacy obligations as any other client data handling.

For some populations, an AI system that makes an error: misclassifies eligibility, mistranslates critical information, or fails to recognize a safety concern: can cause direct harm. These are not reasons to avoid AI, but reasons to require a higher level of oversight and testing before deployment.

• Clients in crisis or safety situationsDomestic violence survivors, individuals in mental health crisis, people experiencing homelessness during extreme weather. These situations require human judgment. An AI chatbot that misreads urgency or follows a script when the situation has escalated beyond the script is a liability, not an asset.
• Clients with limited English proficiencyMachine translation can fail in ways that aren't obvious to English-speaking staff reviewing the output. Have translated materials reviewed by a fluent speaker before using them, especially for anything involving rights, safety, or eligibility.
• Clients with disabilitiesScreen readers, cognitive accessibility, low literacy: AI-generated content isn't automatically accessible. Test any client-facing tool with actual users from your population before wide deployment.
• Clients with past trauma involving automated systemsSome populations: particularly communities that have experienced discriminatory screening in housing, employment, or benefits: have legitimate reasons to distrust automated systems. Transparency about what is AI-generated and what involves a human can help. So can giving clients a way to opt out.

• Test with real users from your population before launchNot staff testing on behalf of clients. Actual users, with actual needs, interacting with the actual tool. The failure modes that matter are the ones your clients encounter.
• Build a clear human escalation pathEvery client-facing AI system needs a well-marked, easy-to-access way to reach a human. If a client can't find it, it doesn't count.
• Disclose that AI is involvedClients have a right to know when they're interacting with an automated system. This is both an ethical baseline and, depending on your state's evolving privacy law, potentially a legal one.
• Define and monitor failure conditionsWhat does the AI do when it doesn't understand a question? What happens if it produces a wrong answer about eligibility or services? Who reviews that interaction? Know the answers before you launch.

• Data use and training disclosureRequire vendors to state explicitly whether customer data is used to train their models, under what conditions, and whether customers can opt out. "We take privacy seriously" is not an answer to this question.
• Data retention and deletion policiesHow long does the vendor retain your data? What happens to it when you cancel? Can you request deletion and within what timeframe? These questions need specific, written answers.
• Subprocessors and third-party accessWho else has access to your data? Many AI tools rely on cloud infrastructure or third-party model providers. You need to know the full chain.
• Compliance certificationsRequire vendors to identify current certifications: SOC 2 Type II, HIPAA Business Associate Agreement (if applicable), FedRAMP, or sector-specific compliance frameworks your funder requires. Ask for documentation, not just claims.
• Incident notification proceduresIf there is a data breach, how quickly will you be notified? What is the vendor's process? This matters for your own reporting obligations.
• Model change notificationAI tools update their underlying models regularly. Require vendors to notify you of material changes that could affect output quality, safety filtering, or data handling: not just feature changes.

• Broad license grants to your dataSome AI tool contracts include language granting the vendor a broad license to use your content and data for unspecified purposes. Read the data use terms carefully, not just the privacy policy.
• Unilateral terms changesClauses allowing the vendor to change terms with minimal notice, or that define continued use as acceptance of new terms. Push for advance notice requirements and the right to exit on material changes.
• Limitation of liability provisionsAI tools sometimes disclaim liability for outputs entirely. Understand what you're agreeing to when something goes wrong. Consider whether your organization can absorb that risk.
• Automatic renewal with long notice windowsSubscription contracts that auto-renew annually and require 60-90 day cancellation notice. Set a calendar reminder the moment you sign.

The most common and most damaging error.

• AI-generated content goes out with wrong statistics, wrong names, or wrong datesAI fills gaps with plausible-sounding content. A donor letter that references the wrong program or the wrong year is a trust problem, not just a typo.
• Grant proposals contain inaccuracies about the organization's own workThis has compliance implications. A funded proposal is a contract. Misrepresentation: even unintentional: creates real liability.
• The fix is simple but requires disciplineEvery AI output gets a human read before it leaves the organization. Build this into the workflow, not as an afterthought. If there isn't time to review it, there isn't time to send it.

A memo, a link, and a 30-minute demo is not training.

• Staff who aren't confident with the tool either avoid it or misuse itBoth outcomes waste the investment. Avoidance means the tool doesn't get used. Misuse means outputs don't get reviewed properly.
• Skeptical staff get left behindThese are often the staff with the most institutional knowledge and the most to contribute to responsible use. Losing their engagement is a real loss.
• Budget two to four hours of hands-on practice per staff memberNot a demonstration: practice. They should leave knowing how to write a prompt, what to do when the output is wrong, and who to call with questions.

Particularly damaging for organizations serving communities with low institutional trust.

• Community members find out after the fact that they were interacting with AIIn mental health, social services, and advocacy contexts, this discovery can feel like a betrayal. Functionally, it is one.
• AI chatbots deployed on websites without clear labelingIf it's not obvious that a responder is automated, it needs to be labeled. This is both an ethical obligation and, in some contexts, a legal one.
• The standard is simple: if AI is involved in a client interaction, the client should knowThis doesn't require a lengthy disclaimer. It requires honesty at the point of contact.

The cheapest option is rarely the right one for organizations handling sensitive data.

• Free tools often have the weakest data privacy termsYour data may be used to train the model. Storage and deletion policies may be vague or nonexistent. Read the terms before you sign up, regardless of cost.
• Consumer tools aren't the same as enterprise toolsThe free version of a general-purpose AI tool is designed for individual use, not for organizations managing client data. Enterprise and nonprofit tiers typically include stronger data controls.
• Price should be one factor among severalSecurity certification, data policy, nonprofit-specific features, and vendor support matter more for organizational use than they do for personal use.

AI tools change constantly. Pricing, features, terms of service, and underlying models all shift: sometimes without much notice.

• Organizations build workflows around a tool and then the tool changes significantlyA price increase, a feature removal, or a change in data policy can disrupt operations that have come to depend on the tool.
• Staff build skills on a specific interface that gets redesignedThis isn't a reason to avoid AI: it's a reason to document your prompts, your workflows, and your policies so they're portable.
• Build flexibility into your AI governance from the startReview tools annually. Keep a short list of alternatives. Don't let a single vendor become so embedded that switching becomes impossible.

Screen visibility and physical access are the easiest vulnerabilities to close. They're also the most frequently ignored.

• Screen locking: every device should lock automatically after a short period of inactivityTwo minutes is reasonable for a shared or open office environment. Staff should also lock manually when stepping away. This applies to any device where AI tools are accessed, including personal phones used for work.
• Screen visibility in open offices and public spacesIf a staff member is using an AI tool to draft a grant proposal or review donor data, that screen is visible to anyone nearby. Positioning desks away from foot traffic, using privacy screens, and establishing norms around sensitive work in public spaces are all worth addressing explicitly.
• Shared workstations and shared loginsIf multiple staff members use the same computer, every AI tool session should be logged in and out individually. Shared logins make it impossible to track who entered what data and create accountability gaps that matter when something goes wrong.
• Printed AI outputsAnything printed from an AI tool: a grant draft, a donor list, a program summary: is physical data. Apply the same handling rules you would to any sensitive document. Shred rather than trash. Don't leave printed materials in common areas.
• Work conversations in public spacesStaff discussing client cases, donor information, or program strategy while using AI tools in coffee shops, co-working spaces, or transit creates real exposure. Establish clear norms about where sensitive AI-assisted work should and shouldn't happen.

The most common security failures in nonprofits aren't technical attacks. They're access control problems.

• Use organizational accounts, not personal ones, for all AI toolsWhen staff sign up for AI tools using personal email addresses, the organization loses visibility and control. If that staff member leaves, the account, along with everything in it, goes with them. All AI tool accounts should be created under organizational email addresses and managed centrally.
• Strong, unique passwords and a password managerReusing passwords across tools is one of the most common ways organizations get compromised. A password manager like Bitwarden (free for nonprofits) makes strong unique passwords manageable without requiring staff to memorize them.
• Two-factor authentication on every AI tool accountMost enterprise and nonprofit-tier AI tools support two-factor authentication. It should be enabled and required. This alone stops the majority of unauthorized account access attempts.
• Personal devices used for work: establish a clear policyStaff checking AI tools on personal phones or home computers creates a security gap you can't fully close. At minimum, require that work-related AI use happens on devices with screen locks, current software updates, and no shared access with family members.
• Network security: public wifi and VPNsUsing AI tools on unsecured public wifi exposes credentials and data in transit. Staff working remotely should use a VPN, especially when accessing tools that contain or process sensitive organizational data. Many VPN services offer nonprofit pricing.

Offboarding is where access control failures most often surface. It requires a specific checklist, not good intentions.

• Revoke access to all AI tools on the day of departureNot the end of the week. The day of. This includes tools the staff member set up independently on organizational accounts. Maintain a running inventory of every tool and every account so nothing gets missed.
• Change shared passwords immediatelyIf any AI tool accounts or organizational credentials were shared: even informally: change them the day someone leaves. This applies to departures of all kinds, including friendly ones.
• Review what data the departing staff member had access toIf the person handled donor data, client information, or sensitive program content through AI tools, document what they accessed and confirm it was governed by your data policy. This matters for compliance and for your own records.
• Retrieve or remotely wipe organizational data from personal devicesIf a staff member used personal devices for work, have a policy in place: agreed to at hiring: that allows you to remove organizational data from those devices upon departure. Without this agreement in place in advance, enforcement is difficult.

Every organization using AI tools needs a short, clear plan for the moment something goes wrong. The plan doesn't need to be long. It needs to exist before you need it.

• Define what counts as a security incident for your organizationUnauthorized access to an AI tool account. A staff member entering client health data into a tool that trains on user inputs. A data breach at a vendor. A printed output left in a public space. Define these scenarios in advance so staff know when to escalate.
• Name a single point of contact for security incidentsStaff need to know exactly who to call and how quickly. Not "email the ED": a named person, a phone number, and a clear expectation of response time. For most small nonprofits this is the ED or operations director.
• Know your notification obligationsDepending on your state and the type of data involved, a security breach may trigger legal notification requirements: to affected individuals, to state regulators, or both. Know these obligations before an incident, not after. Your legal counsel or state nonprofit association can help clarify what applies.
• Notify your vendorsIf you suspect a breach involves a specific AI tool or platform, notify the vendor immediately. Most enterprise and nonprofit-tier tools have security response teams and documented incident reporting processes. Use them.
• Document everythingDate, time, what happened, who was involved, what data was affected, what actions were taken. This documentation matters for compliance, for your board, and for any legal or regulatory process that follows.

Local AI is not just downloading an app. The hardware requirements are real and worth understanding before you commit.

• RAM is the primary constraintMost capable local models require 8 to 16GB of RAM at minimum. A computer with 4GB of RAM (common in older nonprofit hardware) will not run them usably. 16GB is a comfortable floor for smooth performance on smaller models. 32GB opens up more capable options.
• A dedicated GPU accelerates performance significantlyRunning AI models on a CPU alone is slow. A dedicated graphics card (GPU): particularly NVIDIA cards with CUDA support: speeds up processing dramatically. This is the difference between a 30-second response and a 3-second one. Not strictly required, but noticeable.
• Storage for the model filesLocal AI models are large files: anywhere from 4GB to 40GB+ depending on the model. You'll need available disk space and enough remaining for normal operations. An SSD rather than a spinning hard drive improves load times significantly.
• The hardware investment may exceed a year of cloud subscriptionsA computer capable of running local models well costs $800 to $2,000+. For most nonprofits, this only makes financial sense if the privacy requirements are strong enough to justify it, or if you're already planning a hardware refresh.

Local models are not the right starting point for most nonprofits. They become worth considering in specific circumstances.

• Your work involves highly sensitive client data that you cannot risk sending to a third partyMental health records, immigration case details, domestic violence documentation, financial information for vulnerable clients. If the consequence of a vendor data breach would be catastrophic for the people you serve, local processing eliminates that risk entirely.
• Your regulatory environment prohibits third-party data processingSome funding agreements, state regulations, or sector-specific compliance frameworks restrict where data can be processed and stored. If cloud AI tools are incompatible with those requirements, local is the only compliant path.
• You operate in low-connectivity environmentsField offices, rural programs, or disaster response contexts where reliable internet access can't be guaranteed. A local model works offline: a cloud tool doesn't.
• You have the technical capacity to set it up and maintain itLocal AI is not a burden to take on lightly. If your organization has IT staff or a technically capable staff member who can own the setup, maintenance, and security patching, it's viable. Without that capacity, it creates more risk than it removes.

If the use case is right and the hardware is available, local AI is more accessible than it was two years ago. A few tools have made the setup significantly less technical.

• Ollama is the most accessible starting pointA free, open-source tool that handles downloading, running, and managing local AI models with minimal technical setup. Works on Mac, Windows, and Linux. Start at ollama.com. A staff member comfortable with installing software can get a model running in under an hour.
• LM Studio offers a graphical interfaceFor organizations where command-line tools are a barrier, LM Studio provides a desktop application for downloading and running local models without any coding. Free for personal and nonprofit use. lmstudio.ai.
• Start with a smaller model to test your hardwareModels are available in different sizes. Start with a smaller one (7B parameters or less) to confirm your hardware can run it before investing time in a larger, more capable model. Ollama's model library lists hardware requirements for each option.
• Local models still require the same oversight practicesRunning AI locally solves the data transit problem. It does not solve the hallucination problem, the bias problem, or the human oversight requirement. Every output still needs a human read before it's used.

• Minnesota Council of Nonprofits (MNCNonprofits.org)The state's primary nonprofit membership and advocacy organization. Publishes guides, hosts trainings, and maintains a salary and benefits survey used across the sector. Check their Technology Resources section for current AI guidance and peer connections.
• MAP for Nonprofits (mapfornonprofits.org)Provides consulting, capacity building, and technology planning support specifically for Minnesota nonprofits. A good first call if your organization needs hands-on help with a technology adoption plan and doesn't know where to start.
• Propel Nonprofits (propelnonprofits.org)Minneapolis based. Provides financial consulting, lending, and strategic capacity building for nonprofits across Minnesota and the surrounding region. Useful when you are deciding whether an AI subscription is worth a multi-year commitment or whether a hardware investment fits your budget. Their finance team is well known in the sector and their lending arm can bridge gaps that a grant cycle cannot.
• TechSoup (techsoup.org)The national clearinghouse for verified nonprofit discounts on software and technology, including AI tools. Minnesota nonprofits can verify their eligibility and access discounted pricing for Microsoft, Google, Canva, and others through TechSoup before budgeting any tool at full price.
• Charities Review Council (smartgivers.org)Minnesota based accountability and standards organization. Publishes the Meets Standards certification that many Minnesota funders look for when evaluating grantees. Increasingly involved in AI disclosure standards for nonprofits. If you are building a public AI use policy, check their current guidance first.
• Initiative Foundations of MinnesotaSix regional foundations covering greater Minnesota (Initiative Foundation, Northland, Northwest, Southern, Southwest, West Central). If your organization is outside the Twin Cities metro, your regional initiative foundation is often the best first call for technology planning support, small operating grants, and peer connections. Several have been funding AI readiness conversations for rural and small-town nonprofits since 2024.

• Minnesota Government Data Practices Act (MGDPA)If your organization receives state funding or contracts with government agencies, you may be subject to the MGDPA, which governs how government data is classified, handled, and disclosed. AI tools that process government-classified data introduce additional compliance requirements. If this applies to you, confirm your AI data policy addresses MGDPA requirements before any tool goes live. Your legal counsel or the Minnesota Department of Administration can advise.
• Minnesota's privacy laws have evolvedMinnesota enacted a consumer data privacy law in 2023 (effective July 2025) that includes provisions affecting how organizations handle personal data. Nonprofits with specific exemptions should verify whether those exemptions apply to their AI use cases. Get legal guidance before you build workflows around sensitive data.
• Funder-specific data requirementsSeveral major Minnesota funders, including the Otto Bremer Trust, Bush Foundation, and McKnight Foundation, are developing or have published responsible AI frameworks for grantees. Before submitting to any of these funders, check their current guidance on AI use in proposals and program delivery. Proactively disclosing your AI policy can strengthen a relationship with funders who are actively thinking through these questions.

• Minnesota Emerging Leaders in Philanthropy and Nonprofit ManagementPeer networks within Minnesota's nonprofit sector are increasingly hosting conversations about AI adoption. If your organization is a member of MNCNonprofits or connected to a regional United Way, ask whether peer roundtables on technology adoption are available. Learning from an organization that already worked through the same decisions is faster than starting from scratch.
• The Minnesota Council of Foundations (mcf.org)Tracks what major Minnesota funders are thinking and doing on AI. Useful if you want to understand the funder perspective before your next proposal cycle.

• Drafting narrative sections from your program dataFeed the AI your outcomes, population served, program model, and budget context. It produces a structured first draft significantly faster than starting from a blank page. Your job is to make it accurate and specific: AI drafts generalize.
• Adapting existing narratives for new fundersYou've written this program description twenty times for twenty funders. AI can reframe your existing narrative for a new funder's priorities, tone, and word limits in minutes. This is one of the most time-intensive parts of grant work and one of the safest AI applications.
• Summarizing program reports for funder updatesPaste in your data, service numbers, and staff notes. AI produces a readable summary. Staff edit for accuracy and voice. The summary is a starting point, not a finished product.
• Proofreading, tightening, and formattingAI catches grammatical errors, awkward phrasing, and inconsistencies faster than a tired grant writer at the end of a deadline week. Use it as a final pass, not a replacement for review.

• AI invents plausible-sounding statisticsThis is the most dangerous failure mode. AI will generate specific impact numbers, census data, research citations, or program outcomes that sound credible and are simply wrong. Every statistic in an AI-assisted grant narrative must be verified against your actual data before submission. No exceptions.
• Some funders prohibit or restrict AI-assisted proposalsSeveral major foundations have begun requiring disclosure of AI use in grant applications, and a smaller number prohibit it entirely. Check the funder's current guidelines before using AI to draft a proposal. This is especially relevant for Minnesota funders who are actively developing AI policies: see the MN resources section.
• AI doesn't know your communityAI drafts substitute generalized descriptions of "underserved communities" or "at-risk populations" for the specific, grounded language that comes from actually knowing the people you serve. Funders who know your community notice. Edit relentlessly for specificity.
• Misrepresentation is a compliance risk regardless of how it happenedIf an AI-assisted narrative misrepresents your program outcomes, your staff size, your service numbers, or your use of funds, that is still a misrepresentation. The tool that produced it doesn't change your organization's accountability.

• Start with your real data, not a blank promptGive the AI your actual numbers, actual program description, actual population, and actual outcomes before asking it to draft. The quality of the output depends almost entirely on the quality of what you put in.
• Treat every output as a first draft that needs a fact-checkerHave someone other than the AI user read the draft specifically for invented details. Build this into your review process explicitly: not as an afterthought.
• Keep the funder's guidelines open while editingAI drafts don't read RFPs. You do. Make sure the final narrative answers the questions actually asked, not a generalized version of what the AI thought was being asked.
• Document your process for funders who askSome funders will ask whether AI was used. Know your answer before they ask it. "We used AI to produce an initial draft, which was reviewed, fact-checked, and substantially edited by staff" is honest and defensible.